Como você pode ter sucesso como arquiteto de soluções em uma grande organização?

Succeeding as a solution architect in a large organization requires a combination of technical expertise, effective communication skills, and the ability to understand and align technology solutions with business goals. Key points to succeed in the Solution Architect Role Understand Business Goals Communication Skills Technical Proficiency Problem Solving Collaboration Risk Management Customer Focus Adaptability Leadership Skills Continuous Learning Build and Maintain Relationships Measure and Demonstrate Success Solution architect is not just about technical prowess; it's also about being a strategic thinker bridging the gap between technology and business objectives.

Would need to keep involved of the latest technology trends and be ready to adopt those technologies. But ultimately would need to create value and align with the business and must be able to communicate to the business.

In my experience, Solution Architect mostly needs to find balance among the following things: 1. Pragmatic solution over the ‘industry standard’ solution 2. Business and data driven analysis over the personal bias 3. Equal importance to NFRs 4. Skill set of the team 5. Time to market 6. Leadership skills 7. Effective communication skills 8. Continuous learning, unlearning, and relearning

It’s crucial to prioritize understanding the customer’s pain points and needs over focusing solely on technology. By empathizing with the customer, you can develop tailored solutions that address their specific challenges. Ensure a holistic comprehending of the business processes to guarantee the solutions introduced are both relevant and effective.

To succeed as a solution architect in a large organization, it's crucial to stay abreast of the latest technologies, particularly in the realm of artificial intelligence (AI). Integration of AI and automation should be a key focus, enhancing the efficiency and scalability of your solutions. Adopt a holistic approach to solution development, considering long-term perspectives, scalability, and adaptability. Security should be a top priority, with a commitment to adhering to the latest standards and compliance requirements.Finally, invest in continuous professional development, acquiring certifications and engaging in ongoing learning to enhance your skill set and stay ahead in the dynamic field of solution architecture

You also need to understand the business problem you are trying to solve! Solution Architecture only exists to solve business problems. If you can’t link your solution to the business, why would you build it?

Usually in large organizations, there are levels of approvals required to implement any solution. Hence to succeed as Solution Architect in large organization you should not only be able to create a good technical solution you should also be able to present the solution to various stake holder understanding their perspective

For a Solution Architect , the Major Challenge is to understand the Business challenges and addressing then through Process and Technology , so the first hurdle and critical is to identify if its a process issue or technology Gap , once identified proposing the necessary Process change and using Technology in making the change adaption more easier should be the Goal. it imperative that Solution architects should remember that all problems will not be solved with Technology alone , the desired solutions will be more effective when these are solved with Process and Technology and they go long way in user Acceptance and adaption.

What business value is being added is something a solution architect should keep in mind when we start thinking about the designs. The coverage of business goals along with superior technology advancements is a perfect balance to be achieved. Having a focus on business context in designs will have the maximum impact on the overall performance of the product functionally and technically.

In my experience key is the ability to map the business context and objectives to not just the technical solution, but also the business capabilities and individual & team competencies needed to get the most value out of the solution. A technical solution rarely has value on its own.

Effective communication is vital for solution architects, as it's about much more than just conveying information; it's about ensuring understanding, building trust, and fostering collaboration. It involves translating complex technical details into simpler terms for diverse audiences, actively listening to feedback, and proactively keeping stakeholders informed.

In my experience, regular and effective communication fosters a sense of ownership across teams and departments that ultimately promotes more natural collaboration. Crafting clear and concise explanations and linking them to what is important to stakeholders ensures everyone shares a common drive and understanding. Regularly engage with your stakeholders and customers (don’t forget the customer!) to listen, build trust, identify issues and overcome resistance early. Lastly, don’t always wait for the finished product. Involving people early on to build the solution together will avoid wasted effort in refining a solution that is technically non-conformant, not fit for the business context or does not align to the enterprise strategy.

Solution architects must excel in communicating with a diverse range of stakeholders throughout the lifecycle of a solution. The ability to convey ideas clearly, concisely, and persuasively across various communication modes is what distinguishes a competent solution architect. You must possess the skills for clarity and conciseness, versatility in the modes of communication (verbal, written, visual, digital, etc), simplify actual complex technical jargon, learn that you are going to be a mediator, collaborating and negotiating with different teams and individuals.

I´ve always found regularity and consistency to be of great help. This goes very much into the little things. One prominent example is my habit of letting other people know that I may miss an appoinment, or be late. I will let you know. The same principle can be applied to everything, weekly stand-ups, large events etc. Others will know that they will be informed and that takes a lot of guesswork and uncertainty out of the picture. And that is what counts.

Solution architects are influencers. Usually, they do not carry authority. They not only are required to present their viewpoints to diverse people including business and technical but also convince them. Particularly in large organizations, solution architect should create and maintain a stakeholder map to communicate accordingly and effectively.

A bilateral understanding of technology and business enables Solution Architects to build bridges between developers, designers, and users. Translating requirements into stories is one thing, translating technicalities into comprehensible information for non-techies is quite another. Both are just as relevant to create a matter of professionalism, which leads to trust in a common goal and each other.

Approaches become solution if accepted by stakeholders and that acceptance comes with communication. Good business vocabulary not only helps in understanding use cases but also in presenting solution using that vocabulary while comunicating with business. Similarly a technically detailed communication not only helps getting good review comments from technical teams but also helps in testing and development effort. Single page high level solution and/or Mockups which provide end to end big picture in simple understandable terms sometimes really help audience in visualizing the solution. A truthful communication with all pros and cons of the approach and real life examples specific to audience are also very helpful.

Communication is the key. I would prefer to use the word 'effective' communication rather than 'excellent' communication. Medium of communication depends on individual preferences & capabilities. We talk about communication skill in various forum, but most of the times we forget to talk about 'proactive communication'. This style of communication has worked for me really well through out my career. The more proactive you are the more you know about your surroundings.

Communication is crucial to build trust with various stakeholders. Some of the things that helped me in this aspect are: 1) Simplicity: Choice of words keeping in mind the audience 2) Empathy: Understanding your audience. 3) Articulation: Be able to articulate depending on the situation.

To excel as a solution architect in a large organization, effective communication stands as a linchpin. Mastery in articulating intricate technical concepts across diverse channels—verbal, written, visual, and digital—is paramount. Beyond clarity, active listening and empathy foster a collaborative environment, allowing seamless negotiation with different teams. Building trust through transparent communication and adept conflict resolution becomes the bedrock, ensuring the successful navigation of solutions throughout their entire lifecycle.

Reusability cannot be over emphasized. As solution architects we need to be looking for reusable components, constantly harvesting and building repository of already implemented solutions for solving future business requirements. A good searching capability within this repository and a quick way to install a given solution with all its moving parts as and when needed can prove very handy.

While building something new can be exciting, it is often not the most sustainable use of hard to get resources. Our landscapes are full of licensed tooling which we underutilize from a feature perspective or fail to see their full potential and use. With the uprising trend of low-code and no-code tooling, out of the box suites like Office 365 or Google Workspace offer a plethora of possibilities. With the help of coupling solutions like Zapier or Make, your Google sheet can serve as a decent database, Google forms as a decent interface which you didn’t need to build and gmail as that transactional layer that you didn’t need to scale. Consider it as an option when building a small tool or prototyping a business case for future development.

A solution is incomplete or very risky if there are no cost estimates and comparisons. Cost means cost of hardware, software, development, human resource, time and effort etc and if the solution takes these things into account than to save cost it will try to reuse existing assets and standards. As an example cloud is trying to provide prebuilt assets, frameworks, standards etc which organizations can leverage without trying to build and maintain their own but it saves cost only if done properly. :) There can be cases where use of existing assets and standards can be sometimes costly compared to uptaking or building something new, depends on situation and proper understanding and evaluation of options at the time of designing the solution.

I consistently advocate for closing gaps to uncover straightforward solutions. Starting fresh takes time, so it's better to use existing assets or standards for efficient problem-solving. It's like solving a jigsaw puzzle, where identifying or creating missing pieces results in a lasting solution. In my experience, I consistently use the standard SAP tool to bridge gaps and efficiently find solutions to business problems. While existing assets usually lead to problem-solving, there are cases where we may need to build a solution from scratch.

Die Einhaltung von Standards ist nicht nur eine Frage der Effizienz, sondern auch eine der Nachhaltigkeit. In meiner Rolle im eCommerce-Bereich habe ich die schwierigen Lektionen gelernt, die entstehen, wenn man zu Beginn eines Projekts nicht strikt Standards folgt. Wir haben erfahren müssen, dass das nachträgliche Anpassen von Lösungen an Standards weit aufwendiger ist, als sie von Beginn an zu integrieren. Diese Erfahrung kann zu Verzögerungen und zusätzlichen Kosten führen, was die Wichtigkeit der Standardisierung nur bestätigt. Es ist ein wesentlicher Bestandteil meiner Arbeit geworden, sicherzustellen, dass Standards und Best Practices von Anfang an in alle Lösungen einfließen, um eben solche schmerzhaften Nacharbeitungen zu vermeiden.

Most of the times project time lines are stringent. So it makes sense to leverage existing assets & standards where ever possible. At the same, we must avoid creating technical debts that may cause a long lasting, sometimes irreversible damage to the enterprise.

Reusing existing assets may lead to decreased time to value but... to enable this, reuasble assets must be designed for flexibility. Otherwise the effect may be the oposite - reuse of assest that have been tailored for a specific case/customer may be even more time consuming than starting from scratch. This lays in the foundation of software development concept for reusability and it is fully applicable for architecture assets as well.

The best solutions are often boring. Re-use of tools in ways they are not intended can both "complexify", but also reduce the range of components needing to be mastered and maintained.

Deep understanding of the available assets and tools with in the organization helps Solution Architect to propose them and influence buy vs build decisions. It can significantly improve the timeline of solutions and the utilization of assets.

As a solution architect, dedicating some time daily to stay current with emerging technologies and practices is of utmost importance. The catch is to know enough of the applicability, so that you can dig it in detail when a use case comes up. For me, engagement and collaboration with fellow tech enthusiasts in meetups, workshops and webinars provide a more effective learning experience. In an organization, you might not always be involved with ground-up project architecture. Even in an existing solution, you can always find use cases where you can add value via new technologies and practices. But you need to learn to have a balance between introducing changes and meeting the existing commitments. I feel it’s quite important as well.

1. Embrace Growth Mindset: Foster curiosity by exploring new tech trends. See challenges as learning opportunities. Prioritize continuous learning as a habit, not just a duty. 2. Diversify Learning Sources: Pursue formal education like online courses or certifications. Stay informed through informal channels like blogs and podcasts. Gain hands-on experience through activities like hackathons and personal projects. 3. Network and Collaborate: Connect with peers in professional communities and seek mentorship from experienced architects. Share knowledge through writing, presentations, and mentoring.

Ability to achieve results, by choosing optimal solutions working with different teams to align on the solution approach. Ability to decide the trade off and convince stakeholders with solution diagrams, prototypes or demos . Curiosity and ability to learn new concepts and try new learning with hands on approach. Actively participate in solutioning, or review for different kinds of problems . Keep oneself updated by attending & contributing in seminars, thought leadership etc.

As someone who has been in the architect and CTO roles over the years I can say that if you are not staying up with emerging technologies you are not taking your job seriously. The key to designing solutions is to understand the current options and not rely on the old ways of doing things. Could be that old school is the best answer but you will never know unless you are aware of all the new approaches. I have seen great solutions architects in my years at Expedia, Microsoft and Splunk while I was there and the reason is they each were up to date on new trends and tech and knew when and where to apply them.

In the tech world, new ideas and changes happen all the time. As a Solution Architect, it's really important to stay up to date with these changes to create strong, future-ready designs. Continuous learning isn’t just helpful—it’s a must. Over time, we've seen how quickly technology moves forward—what was new a few years ago can become old fast. Keeping up with the latest tools, methods, and best practices helps you build flexible, reliable solutions that fit today’s business needs. By constantly learning, you stay valuable and can handle complex projects more effectively.

Keeping your up-skill & cross-skill is most important for solution architecture to be successful. Technologies continue to evolve with version, roadmap and AI enablement. One need to not only know about technical deep in one tech. but equally know about the competitor landscape. no client would like to be vendor lock-in and how can there are possibility to move data across systems with appropriate architecture. E.g.Databricks comes with Delta Live table, liquid clustering and snowflake coming up with Iceberg, Dynamic table are such examples that should be known to SA and team. Therefore, it is necessary to continue reading, partner training, webinar, blog are some of great resources.

Keep up pace with new technology emerging. Create learning plans in chunk for bigger goal to reach into end state. Engage yourself with like minded people to learn the new trends and industry demand and prepare yourself.

One thing in particular that I’ve found to be have a lasting effect when it comes to active learning and updating skills in a professional setting is to do so in the open. By “open” I mean asking questions in public channels, trying out new ideas and technologies, inviting your colleagues and peers to offer their help and share their experiences. As long as the tone is respectful and the conversation is actually about the subject matter I’ve seen that this tends to lower the threshold for others to follow suit. This in turn creates psychological safety in which both learning and experimentation can thrive. So yes, seek out the knowledge and learnings - but for the real long term benefits, do so openly and fearlessly.

Having a growth mindset is non-negotiable. Here are three ways I keep fresh: 1. Continuous Learning: Commit regular time to development! If you are ‘too busy’ to learn you are creating a problem for yourself, your team and your business in the long run. Take advantage of the many free online courses, workshops, and industry conferences available from the comfort of your desk. 2. Hands-on Projects: Undertake personal or side projects to experiment with new technologies and deepen your understanding while tackling real-world challenges. 3. Collaboration and Networking: Connect with peers and experts through mentorship, articles, meetups, and online communities to share experiences and hear diverse perspectives.

No matter how good, how experienced or knowledgeable you are, no solution should generaly proceed without a peer review. You might have miss details or sometime the point. If you can't demonstrate and convince your peer of the value of your solution, maybe it needs to be rethinked

For solution architects, the journey towards professional excellence is not a solitary one. It involves seeking constructive feedback and engaging in mentorship relationships. Learning from experienced and senior architects provides invaluable insights into enhancing one's skills and advancing career development. There is a saying in my culture: "you don't learn the job, you steal the job". If you are always under the impression that somebody that you know has more knowledge on an area and you find it intriguing and want to learn it..you are doing the right thing.

I think there is so much benefit in sharing scenarios/use cases/challenges on a regular basis within your team (and with other teams inside your org that you also may feel would benefit). This shared knowledge promotes growth and trust and serves as a motivational tool where we all strive to become better Architects. It's definitely worked well for us as a team using this collaborative approach and asking for feedback!

I have been in this game a long time now and have earned the grey beard and can tell you that if you are not working collaboratively you will not succeed. In some cases that may be just ask peers for a review to ensure you did not miss anything and in others it may be a room full of people criticizing your work. However you are forced or choose to seek feedback you should learn something from each encounter. Also when it comes to advancing my career I can say that I would never have gotten to where I am without having many mentors over the years that were willing to share their knowledge when asked. I try to pass that forward and help anyone who asks.

Build a network within and outside your organization. Attend industry events, join professional groups, and engage in online forums to connect with other solution architects. Receive feedback not only on technical aspects but also on your soft skills, such as communication, leadership, and collaboration.

The biggest problem people face in large organisation, when dealing in Solution Architecture is too much iterations and longer decision making time. But you can turn this to your advantage by creating feedback loops & early highlighting the findings and challenges. Do not wait for a formal meeting, if you find something important, try to share it as early as possible. Avoid being too much formal in your approach. Call instead of Mail, Meet in person instead of call and discuss instead of complaining. Try to have diverged stakeholders from product to sales to delivery to support. Seal their inputs and understand their perspectives. Try to make decision collectively instead of seeking a review if your decision.

Whether you are a solution architect internally for a large organization, or a presales solution architect with a large service provider, I recommend you play your part in defining the stable triangle of a Deliverable solution with high-integrity Operations focused on maximizing Outcomes for the end user.

You should be open to understanding and listening to your team and developers. They are the ones who will implement the solution and deal with the technical challenges and issues. Therefore, they need to be involved and consulted in the design process. However, I often see SAs who are too attached to a particular technology and/or a design, and they ignore or dismiss the objections or suggestions. This can lead to conflicts, misunderstandings, and poor outcomes. They should be willing to take critique and explain why the design proposed is best suited for the problem and be open to revising the design as per the feedback if needed. This can help to build trust, collaboration, and quality in the solution.

Building partnerships & alliances is an important part of being a good solution architect as well as building social proof that the systems you build are valuable. This comes through relationships, feedback & mentorship.

There are two aspects to take care: 1. It's essential to make sure that requirements are understood in it's true sense, come up with best possible solution, vet it with respective stakeholders early in the cycle and proceed to next steps. Seamless adoption by endusers is the KEY for any solution to succeed. 2. Ensure to get the best of latest is being leveraged while defining solutions and it is important to not over engineer the solution. To take care of an unbiased evaluation, it requires mentoring experienced professional.

FLEXIBILITY: One needs to be flexible and cannot be rigid with the approach. The ultimate goal is the solution to be acceptable by all the stakeholders. Sometimes the best solution does not work if does not align with the customers expectation. In such a case the solution architect should be flexible to change the solution and cannot be rigid. Also it is important to come up with multiple options. As mentioned above communication and alignment is very important

In my experience, designing systems that are fit for purpose involves aligning technical solutions with business goals and culture. For example, when working on a project for a financial services company, we made sure to consider the organization's operating model, ensuring our solution integrated or smoothly transitioned with the existing processes. This approach fostered smoother adoption. I firmly believe that taking into account the operating model is vital for creating effective and resilient solutions.

1.Embrace criticism and remain open to new ideas. This fosters continuous improvement and innovation 2. You must possess not only robust technical expertise but also a profound understanding of business concepts. This dual knowledge base allows for the creation of solutions that are not only technically sound but also aligned with business objectives. 3.To thoroughly evaluate potential solutions, employ tools such as a business model canvas, SWOT analysis,etc. to provide a structured approach to understanding the feasibility and impact of each solution. 4.Develop and maintain a dynamic road map that can adapt to changing business needs and technological advancements. This ensures that the solutions remain relevant and can evolve over time.

Don't recreate the wheel for every solution. What is reusable? Maybe you just need to tweak a previous solution to fit the new problem statement. What lessons learned were helpful to avoid risk in the new project? Treat each project/solution as a learning experience and reuse that knowledge to help you build better solutions faster.

In my experience, placing a signficant emphasis on non-functional qualities is critical. This is a conversation that the Solution Archictect is in a unique postion to lead. Take care not to let non-functional requirements cascade down to you. Instead, demonstrate leadership by being prepared to propose what the requirements should or can be. Remember that there are other stakeholders that have to live with non-functional quality decisions, such as IT operations teams who are accountable for achieving service levels and need their own solutions to monitor and respond. Lastly, look to your EA team to provide direction, support, coaching, and solution reviews.

Customer First : Sometimes customer is mistaken as someone external who is buying a product or service and paying the company for that. But customer might not always be an external entity. Most often customers are internal stakeholders who are going to be a beneficiary or and end user of a product/ service you are going to deliver. For example a business user or an accountant can be a customer for an App you are going to deliver in an enterprise. As a Solution architect, such customer should always be the focal point while designing a solution.

A Solution Architect should have a good capacity of abstraction: do not “lock-in” on a technology and have a good bird-eye vision to be able to logically connect the dots of larger organizations. Technology will naturally follow. Nevertheless a good SA also must have the knowledge of components and services, especially in a cloud-oriented world, where almost everything is a service: here the SA can focus on a technology stack, enable and scale it, leveraging its capabilities.

Impact Analysis: As a Solution Architect, responsible to do architecture impact analysis, technology assessments and propose solutions to ensure quality deliverables without compromising functional and non-functional requirements. Advise business to make right technology choices.

A very important aspect of being a Solution Architect is a strong collaboration with the development team. Solution Architects can't work in isolation from the development work. Solutions created and designed have to fit well into the current application architecture. The ultimate goal is to create valuable functionality, but sometimes small changes could result in a significant difference in the effort needed to achieve it. Taking it into consideration makes the solution well fitted to the business and technical needs.