Solutions Architecture

If you are looking for a comprehensive meta-model describing detailed causation relationships and semantic relationships between activities and artifacts in Enterprise Architecure, don’t look here. Instead, we suggest you start with an established model such as Nick Malick’s Enterprise Business Motivation Model (EBMM) or the Zachmann Framework. The purpose of this article is simple – it provides a pragmatic description of key architectural components as well as the difference between the roles of the Enterprise and Solutions Architect. Let’s explore the elements involved first.

Key Role Elements Involved

Business Architecture is concerned with the alignment of business and its dynamic capabilities (principally in most organisations specifically the alignment of business and IT). It achieves this by forming a number of holistic views that enable scenario planning, impact assessment and decision making to be achieved. These views include the business processes, the organisation structure, the application portfolio and the capabilities view of the organisation.

Maintained in step with the business architecture, the Information Architecture addresses the entities of the business, their structure, meaning and canonical forms. Information Architecture also considers the disposition and placement of data, its rules and structure and constraints placed on it. It is concerned with the elaboration of a ubiquitous language that can be shared between all stakeholders, including business and architecture.

The Technology Architecture steps from the domain of What to How. It is concerned with elaboration of the organisation strategy into a set of reference architectures, patterns and guidelines. These are supported by development standards, the service catalogue underpinning capability reuse and a base architecture model that provides a conceptual reference view for the organisation’s architecture fulfilment.

Essential to realizing the target state of any solution, Data Architecture describes how data is processed, stored, and utilized in an information system or across systems. It provides criteria for data processing operations so as to make it possible to design data flows and also control the flow of data in the system.The Data Architect is typically responsible for defining the target state, aligning during development and then following up to ensure enhancements are done in the spirit of the original blueprint

The functions defined

All of these artifacts frame and facilitate the work of the Solutions Architect. The interaction between disciplines is supported by Vitality and Governance processes that not only ensure conformance, but also continued development of the Architecture.Hence, the role of the Solutions Architect is more focussed and suited to project-related than organisational governance initiatives.

There are many different interpretations for the role of an Enterprise Architect. The role between enterprise and solutions architcture is even often blurred. This is understandible, given “enterprise architecture” have many different meanings despite well-known frameworks like Zachmann and TOGAF. We often find that there are only particular aspects examined to properly define these roles. To compound the issue, information technology professionals scope enterprise architecture differently. Some IT professionals view enterprise architecture as a more structured activity with many moving parts such as architecture strategy, architecture patterns, principles, architecture design, business architecture, and IT governance. Others may just focus on the technical aspects rather than the business, operational, or strategic aspects. Many view enterprise architecture as an IT-only issue. In many cases, it is important that the enterprise architecture group speak in both business and IT terms. In our opinion, most importantly, EA should be neutral in their functions in order to ensure architectural continuity and proper usage of its functions as opposed to being a ‘red tape’ function which can be seen by IT and business stakeholders as a ‘reactive obstacle’ to decisionmaking. The function of EA should thus be well balanced between governance and practical guidance to ultimately ensure that through governance  the implementation of its selected/defined framework, throughout design to implementation, the solutions architects are enabled and guided. Yet its challenge is to remain relevant and actionable as opposed to its functions purely being focussed on technical aspects, playing ‘catch-up’ and documenting architectural outcomes in architecture models.

Bottom line: The difference summarised

In simple terms, the difference can hence be denoted as a function of project implementation through framework facilitation for Solutions Architecture, while the dominant theme of Enterprise Architecture remains focused toward IT and business governance though defining the same framework in line with IT and business strategy. The two should in fact often overlap for the sake of consistent alignment and implementation of architectural frameworks, however, the level of its audience and stakeholder engagement should be split between top management, senior management and project-related stakeholders.