One of the questions I often get is “What does an architect do?” Although there are many day-to-day activities like attending too many meetings, the following list gets to the heart of how architects bring value to their organization. This list is presented in the context of a project to provide a flow, but a project context is not required. As well, the list applies to all architects including enterprise, business, application, solution, data, network, security and infrastructure.
Michael Rosen, Chief Scientist, Wilton Consulting Group; email@example.com
Michael will be teaching the course, Great Skills Make Great Architects 24-25 October 2019, London
Michael will also be speaking at the IRM UK Enterprise Architecture & Business Process Management Conference Europe 2019, London on the subject ‘The Future of Architecture‘
1. Inquire – Architects are asked to solve specific problems. Getting to the core of the problem and soliciting requirements is the first step in addressing any given set of requirements. Of course, the requirements are often vague, and presented in the limited focus of a specific domain. So, the inquiry must solicit both specific requirements and goals, as well as an understanding of how those requirements fit into a broader context (such as the enterprise). One of the most important things an architect should do during these activities are to question assumptions, both implicit and explicit and apply the concepts of critical thinking.
2. Integrate – Architects (especially enterprise architects) act as a bridge between a given project or design and how that project fits into the broader context. One of the major benefits that an architect brings to the enterprise is in integrating the solution for the particular project with the business domain, enterprise concerns, industry standards, established patterns, and best practices.
Analyze – Next, an architect has to analyze the information that they have collected. The analysis consists of answering three architectural questions: 1) What are the key elements of the problem or solution? 2) What are the relationships between them? and 3) How do they combine together to provide value? Often analysis will be broken into two important parts, a model of the problem, and a model of the solution. The first is used to precisely describe the requirements within the broader perspective and without any bias toward how it might be implemented. The solution model then describes (at a high level) how the problem will be solved in terms of IT concepts, services, systems and applications.
Conceptualize – Once the overall, integrated solution is framed, the architect needs to create a conceptual vision of the solution. This will typically be in the form of a ‘conceptual architecture diagram’, a drawing that shows the major users / channels of the system, the other systems it has to interact with, the major logical functions and data that it must perform or use, and that establishes the scope of the project within those pieces.
Abstract – The conceptual architecture serves to communicate the overall concepts to a broad audience and so much provide key information without overwhelming the recipients with unnecessary detail. Architects use abstraction techniques to highlight the key concepts. The architect also has to communicate the key details to specific audiences. This can be accomplished through the use of architectural viewpoints, such as business, information, application, and technology perspectives. Abstraction can be defined as the suppression of irrelevant detail. So one key abstraction is to apply separation of concerns to establish (filter) what details are and are not important for that viewpoint. Within each perspective, the viewpoint will also be presented in different levels of abstraction, often referred to as ‘conceptual, logical and physical’ architectures (not all perspectives will have all of these levels).
Visualize – They say a picture is worth a thousand words. It is also an excellent way to represent the architectural drawings and models at each level of abstraction. So, another key skill and function of the architect is to create visual renditions of the different abstractions and viewpoints.
Formalize – Of course, architecture needs to be more than just pretty pictures. It needs to be specific enough to unambiguously communicate the details to whoever is going to implement the architecture. An architectural ‘specification’ is the usual approach to formalization. But, the specification does not necessarily have to be a document. A formal visualization in the form of a complete and precise model, expressed in industry standard notation, may often be preferred because a formal model can be implemented and enforced within a modeling tool or design framework. The formal specification may be called a ‘reference architecture’.
Communicate – This is probably the single most important aspect of an architect’s job. Fundamentally, architects are in the role of communicator. After they establish and formalize a solution, they need to communicate that solution as well as its importance and value throughout the organization. Almost always, architects act from a position without direct authority over those who would use the architecture. Thus, the only tool available is to influence potential users by explaining how it is important and in their own best interest to follow the architecture.
Enable – Even the best designed, formalized and communicated architecture may not be successful. The equation for architecture value is actually pretty straightforward. If using architecture will make someone’s job easier, they’ll use it. If it adds extra steps and work, without adding extra value, it will be ignored. Of course, achieving this goal is anything but simple, but a key to achieving architecture’s goal of influencing IT projects and systems depends on the extent to which architects enable the target audience to easily use the architecture.
Assist – Finally, one of the primary enablers for architecture is to actively assist stakeholders in using it. This is the single most important activity an architect can do to make their architecture real. Virtually all successful architecture programs include some aspect of consulting to projects or other stakeholders.
Another important question is “What are the key skills that an architect needs to perform these functions. I’ll list them below and expand on them more in a later article.
- Critical Thinking
- System Thinking
The list of skills and activities is not complete, but hopefully will give you some food for thought. Is this what you or architects at your organization do? Are you missing or skipping some important steps? Are you spending time on the right activities that bring value to your organization?
As always, I’d love to hear your feedback. Write with your thoughts, comments, suggestions, questions.
Mike Rosen is Chief Scientist at Wilton Consulting Group, providing advice to IT and business leader and architects on using architecture for digital transformation and improved decision making. He is also a Founding Member and VP of the Business Architecture Guild. Mr. Rosen has helped dozens of enterprises create transformation strategies, implement enterprise solutions and create or improve their architecture programs. He has 40 years of technical leadership experience architecting, designing, and developing software applications and products, including roles as CTO, chief architect, product architect, technical leader, and developer for commercial middleware products from IONA, BEA and Digital. Mr. Rosen is a well-known international speaker and author of 3 books and hundreds of articles.
Copyright Michael Rosen, Chief Scientist, Wilton Consulting Group