Johannesburg, 19 Jul 2016
People are more familiar with the role of the enterprise architect than that of the solution architect, says Marius Snel, CEO, owner and enterprise architect at Knotion Consulting. This was confirmed by a client, who incorrectly commented: "When the solution architecture is done, I should be able to start coding."
The confusion is a reality, and I realised that when a trainee recently asked: "How close should the enterprise architect and the solution architect work together? Is the one merely a governance authority?"
In the TOGAF 9.1 manual, the term "solution architect" is only referred to in chapter 52.6.2, where it is defined as: "The solution architect has the responsibility for architectural design and documentation at a system or subsystem level, such as management or security. A solution architect may shield the enterprise/segment architect from the unnecessary details of the systems, products, and/or technologies. The focus of the solution architect is on system technology solutions; for example, a component of a solution such as enterprise data warehousing."
When researching the title and definition on Google, you come across an array of different interpretations and definitions. Wikipedia defines it as: "A solution architect, ... [is] typically part of the solution development team; the solution architect translates requirements created by functional analysts into the architecture for that solution and describing it through architecture and design artefacts. The rest of the development team then uses those artefacts to implement the solution." As per the comment of a blogger, the above definition sounds very much like the role description of a systems analyst, only with the prospect of an increased income.
An alternative option is to become a solution architect for a specific product, case in point being MCSD: Azure Solutions Architect. So, where does the solution architect stop and systems analyst start?
Knotion Consulting developed several models, one of which was developed with the specific purpose of assisting people to obtain a better understanding of these roles.
Starting with the enterprise architect (EA) on the left of the V-Model. The EA needs a clear understanding of the business architecture, which includes the goals, objectives, role models and capabilities, concluding with the processes. The next step is for the EA to identify the data and application architecture building blocks required to support the business. The application building blocks include application components and functions, while the data building blocks include data groups and entities. The architecture building blocks are technology-agnostic. Lastly, the EA identifies the system software, hardware and network technology building blocks, again very much technology agnostic.
At this point, the EA may have either created a strategic architecture or a segment architecture. In the case of a strategic architecture, it forms the basis for a segment architecture. Whether it is a strategic or segment architecture, the EA will go through the same steps, only at a different level of granularity.
In the next step, the EA works with the solution architect (SA) to identify suitable solution building blocks, starting at the technology layer. The EA works "top down", while the SA works "bottom up". Once the suitable technology solution building blocks have been identified, the solution architect determines the technology gap between the architecture building blocks and the solution building blocks, which is the technology delta. Following the same process, the application and data solution building blocks are compared to the architecture building blocks and the delta is established.
Finally, based on the selected product, especially if a "commercially off the shelf" (COTS) product is selected, which comes with its own processes, a delta in the business process domain may exist.
Once all the deltas have been identified, the solution architect combines them and determines 'what' should be done to close these gaps, as well as the amount of iterations or transitions. These results are handed over to a systems analyst, who understands the products well enough to create a design focusing on the 'how' to close the gaps.
In conclusion, there should be a well-defined working relationship between the EA and the SA. Ideally, this should not be a governance relationship in terms of policing, but rather one of supporting each other while working towards a common goal. Not only should the SA have a close relationship with the EA, but also with the development team, ensuring the end solution agrees with the vision of both the business and the EA.
Finally, both an EA and an SA can be supported by a team of business, data, application and technology architects.