Among all other IT roles, an architect is characterized by the breadth and depth of his or her business and technical knowledge. From a business perspective, an architect must understand the business strategy, the environment trends and the business processes. From a technology perspective, an architect must monitor and leverage emerging technologies, have in-depth knowledge of critical technologies to the business, and understand the invest-maintain-retire technology lifecycle. In addition, the architect must bring business and technology together making people and the business they serve more successful. All of this communicating and collaborating to hundreds of people along the way.
Figure 1 - Architect's Business and Technical Knowledge
Given the challenges involved in being effective and efficient in all these areas, architects need to develop certain habits. The purpose of this blog is to discuss four habits that are needed to make an architect successful.
Habit #1 - Understand the business context
Since architects are employed to make people, and the businesses they serve, more successful, perhaps the most important skill of an architect is to be able to listen attentively to the business and its problems. In order to be effective, an architect needs a strong understanding of business goals, strategies, critical capabilities, people, process, data, and key metrics.
Business Goals and Strategies - Business goals describe what a company wants to be (e.g. make shareholders more successful) and business strategies articulate how a company plans to achieve these goals. An architect must become familiar with business goals and strategies because they drive the creation of business capabilities and drive the more technical subsequent decision making.
Business Capabilities - Business capabilities are a combination of people, process, data and technology that needs to be in place in order for a company to implement its business strategy and achieve its business goals. McKinsey's survey on reasons "why strategy fails" shows that the majority (approximately 40%) of strategies fail because companies simply lack the required capabilities for implementation of the business strategy. More importantly, the quality of these business capabilities and how they are used to assemble business processes are a source of competitive advantage for companies. One of the architect's main goals is to work side by side with his business and technical teams to assemble business capabilities that can help a company achieve its goals.
People, Process, Data, and Technology - Before shifting into visioning and problem solving mode, an architect must always become familiar with the current state of people, process, data and technology. The current state not only represents the starting point of roadmaps but also contains valuable information about the current pain points faced by a company. More importantly, architects that can articulate the current state gain instantly credibility with the team and are more capable of facilitating the transition.
-
Data - Data is the foundation of IT and a critical success factor for companies, people and architects. An architect familiar with the current data is capable of quickly bringing hard evidence to discussions, that otherwise would stay at the conceptual level. In addition, while designing future solutions, an architect familiar with current data is capable of working to carefully eliminate constraints found in the current data structures. Finally, the current data is often the source of volumetrics, business requirements, migration requirements, and business case quantitative evidence.
-
Processes - Business processes are collections of interrelated tasks involving automated and human steps. An in-depth understanding of the current processes enables the architect to identify how the introduction of new business capabilities will impact these existing automated and human steps.
-
People - Technology always brings change to people's lives. This is a fundamental concept that an architect must understand and take into consideration when solving business problems. First, IT is almost always about making people and systems more efficient. Second, employees, customers, and vendors impacted by a project often need support, training and or communications about new processes and systems. Third, people, both in the business and technical side, are either the most important allies of an architect or one of his or her worst enemies.
-
Technology - Current technical capabilities supporting the business must be understood by an architect. First, current systems and technology can be in different stages of their lifecycle (i.e. maintain, retire, invest) and an architect should make recommendations compatible with the lifecycle of technologies. Second, current systems may need to be integrated into the final solution and introducing significant constraints into the final solution. Third, reverse engineering of systems if often the only viable way to capture requirements for a new system.
Metrics and key performance indicators (KPIs) - Always starting with the end in mind, an architect must define or have a clear understanding of the metrics and KPIs that define success. Companies often define several KPIs to measure progress toward goals. An effective architect understands these KPIs and other metrics. For example, if a system has stringent performance requirements, a mechanism to measure performance must be in place. If reliability of transaction process is a requirement, a mechanism to measure how many transactions are processed successfully through the system must be in place. If improving customer satisfaction is a goal of a new system, a mechanism to measure customer satisfaction must be in place.
Habit #2 - Understand technical capabilities
An architect must have conceptual and hands-on knowledge of a diverse set of technologies typically applied to solving business problems. The breadth and depth of an architect's technical knowledge places a constraint in the quality of solutions he or she is capable of providing.
Monitor new technology capabilities - An effective architect is constantly monitoring new technologies. This is important due to potential business capabilities that can be assembled from these new technologies. This is best achieved through a combination of constant research and collaboration with other fellow architects. Most of the time, however, there is no need to go deep unless the technology is truly transformational or disruptive to the business, or it is moving very fast towards widespread adoption. The Gartner Hype Cycle is an interesting conceptual tool that exemplifies this point.
Figure 2 - Technology evolution graph
Know critical technologies in depth - An architect must know certain technologies in depth. This is important because an architect should not design solutions or recommend technologies that he or she has no experience with. First, the quality of his or her solutions will be questionable. Second, an architect is often the last resort for business and technical resources when questions arise or things go wrong. Third, an architect with no in-depth knowledge is typically unable to gain credibility with both the business and technical communities.
Acquiring this in-depth knowledge represents a challenge for every architect that must always look for opportunities within project and in lab setting to study these critical technologies.
Habit #3 - Make people successful
An effective architect makes people, and the companies they serve, more successful by solving their problems. An architect is typically engaged in a variety of problems, ranging from the definition of a holistic future state vision to rescuing a business in a SWAT-like effort. In order to accomplish this, an effective architect always starts by defining success, solving problems, and supporting the team to the conclusion of the efforts.
Define success
Manage Expectations - Working as a liaison between business and technology, an architect plays a key role in managing expectations (a.k.a. requirements). Defining requirements is a non trivial activity. First, requirements are hard to capture in writing. Second, requirements frequently change to accommodate new expectation from the business. Third, the stakeholders' ability to convey and the analysts' ability to understand requirements increase throughout the project. This leads to re-interpreting requirements. Forth, large-scale systems have thousands of requirements that can become hard to interpret without the original context.
Define the business case - Success is tied to the accomplishment of the qualitative and quantitative benefits described in a formal or informal business case. An architect is often involved in supporting the definition of multiple aspects of a business case, including:
- Approach, Phases, Activities, Deliverables
- Cost Estimates
- Resource requirements
Demonstrate value - Solutions to problems do not always have self explanatory benefits. An architect must demonstrate these benefits by constantly connecting the solution to the problem, defining quantitative metrics that show the positive impact of the solution, and communicating often to all stakeholders in the project.
Solve Problems
Seek multiple solutions to problems - Often, the best solution to a problem is no solution. Before jumping into problem solving mode, an architect must always question and understand the problem in-depth. The best solution to any problem is always eliminating the problem altogether. For example, the problem of printing documents can be eliminated through electronic communications. The problem of managing vendor data internally can be eliminated by having vendors maintain their own information.
If the problem needs to be solved, then multiple solutions should be sought. If only one solution is known, chances are one has not thought long enough about the problem. The discussion and implementation of multiple solutions are the foundation of good solutions. Multiple solutions enable the analysis of trade-offs (i.e. pros and cons) that ultimately lead to solid decision making.
Seek simple solutions - An architect must seek simple solutions within the context and constraints of a business situation. Large-scale systems tend to be complex, even when built on simple initial solutions. Business process, data and technologies solutions should start as simple as possible to more easily absorb the accidental complexity common to software problems. For example, eliminating a simple integration point or a component from a possible solution may eliminate hundreds of hours of development work, test, defects, and performance problems. Perfect solutions are always the enemy of good solutions. Perfect solutions may actually be the biggest culprit for increased complexity. In an attempt to cover all current and future requirements, or apply the "perfect" solution pattern, architects often create very complex solutions that can lead projects to failures. After all, there is no perfect solution because every solution is subject to several constraints that will force an architect to make trade-off decisions.
Evaluate trade-offs - The solution to any problem is subject to competing constraints. For example, higher security often comes at the expense of performance; higher quality comes at the expense of costs, a quick coding workaround comes at the expense of maintainability. An architect knows how articulate this trade-offs and to offer recommendations that fit within the context of the problem. Despite the repeatability of certain patterns, the business context dictates how the trade-offs will be made and how the final solution will look like.
Leverage solution patterns, principles and best practices - Even though solutions are always dependent on their business context, an architect must know certain solution patterns. Solution patterns are general reusable solutions to commonly recurring problems. Solution patterns have to be used with caution because they may lead to a more complex solution.
Document the rationale for your solutions - Even the best solutions are questioned more than once during and after the project. Because of the ever evolving constraints in any business environment, the rationale for a solution must be documented. Sooner or later an architect will be questioned about why certain design decisions were made.
Support and teach
Making people successful and solving problems are intrinsically an iterative process. Problems are never 100% solved and people are never 100% successful. Therefore, an architect must be effective in providing on-going support to his team and establishing the mechanisms that will govern the evolution of his or her solutions.
Support the team - An effective architect stands next to the team always looking for opportunities to help by providing guidance on unexpected business and technology problems, taking ownership and removing road blocks that are slowing down the team, and working with project managers to make adjustments to the plan to maximize the chances of success.
Follow-up to implementation - More than 80% of the lifecycle of a new business and technology solution is spent in the maintenance and support phase. An effective architect never abandons the team prior to delivery, but closely supports his or her solutions until they are stable in "production" mode.
Establish governance - The dynamic nature of businesses lead to solutions that are never final and have to constantly adapt. An architect recognizes this and works with stakeholders to create governance mechanisms including Project Management Offices (PMO), Enterprise Architecture Office (EAO), change management boards, prioritization boards, review boards. These governance mechanisms are critical because companies have limited resources and must deploy these resources wisely. Effective governance mechanisms enable a group of people to establish a pattern of adapting solution with positive outcomes.
Teach and Coach - Teaching and coaching are integral part of an effective architect's activities and critical to making people more successful. Teaching and Coaching is what enables people to become self sufficient in solving problems and maintaining solutions by themselves. Curiously, the more an architect engages in teaching and coaching, the more he or she learns about a topic. Team members always bring new points of view or questions that contribute to the architect's knowledge of a topic.
Habit #4 - Communicate and collaborate
In a large scale project, an architect needs to communicate and collaborate effectively with hundreds of people around the globe. This translates into bridging gaps and creating a shared understanding of the future state and the path to get there.
Establish strong relationship with the business and technology teams - An architect can only be effective if a strong relationship is established across his business and technical counterparts. After all, people continue to be the most critical success factor in technology solutions. An architect is in a unique position to establish these relationships because of his or her ability to explain the problems and solutions to the business team, in business terms, and to the technical team, in technical terms. This shared understanding of problems, solutions, and the benefits that the solutions will bring to each individual are a good starting point for very strong relationships.
Document and explain solutions at the right level - An effective architect knows how to properly document and explain solutions according to the audience. In the course of a large scale project, the same concepts and solutions are explained to different constituents hundreds of times. An effective architect uses a combination of standard templates, documents, spreadsheets, presentations, and models to convey the same idea to different audiences. This includes the high level view, the low level view and, more importantly, the middle ground connecting views.
Bridge the gap between business and technology - Technology exists for making people, and the business they serve, more effective and successful. Therefore, it is only when technology finds its way into a business application that value is realized. One of the most important attributes of an effective architect is his or her ability to bridge the gap that naturally exists between business and technology people. Sometimes the gap is bridged from the business into technology. Starting at the with a business problem posed by a business person, an architect collaborates with the technical and business community to define the changes to people, processes, data and technology that will solve the problem. Other times the gap is bridged from technology into the business. Starting with an architect's knowledge of new technologies, an architect collaborates with business and technology community to assemble new business capabilities that can result in competitive advantage to the business.
Figure 3 - Business strategy and capabilities
Bridge the gap between the current and future state - Any design of a future state architecture with no regards to the path to get there is subject to failure. This is probably the most critical factor that leads "ivory tower" future state architectures to fail. An effective architect knows that laying out the roadmap is as important as defining the future state. In order to demonstrate the path, an effective architect does not hesitate in being "hands-on" during the first iterations of the future state architecture.
Be Humble - As architects acquire more and more knowledge about business and technologies, become influencial on both business and technology teams and solve complex problems, is not uncommon for architects to become egotistical. The moment this happens, however, the less capable an architect becomes of listening attentively to people and collaborating in finding solution to problems. With the breadth of knowledge required from an architect and the complexity of certain problems, it is almost certain that better ideas and approaches will come from both the business and technical teams. An effective architect is always humble to understand that, most likely, his ideas and solutions are often neither the only ones nor the best ones.
