'Architectural realization is a way of thinking and not a concrete technology implementation.' It is however, supported by frameworks, patterns and best practices that complement the mindset. It is the role of the enterprise architect (EA) and his team to both define and deliver a technical roadmap that supports the short and long-term strategic objectives of the business.
Thus, the EA must be one who understands all the architectural forces and more importantly the technology components that allow him/her or them to deliver a transitional and target architecture. Over the past decade a new function / job title has risen in prominence, i.e. one of the 'architect'.
In many cases the title architect has become a generic name for a specific systems domain expert and has resulted in a situation, where today, we have infrastructure, data, applications, network, and solutions architects. In fact, recent adverts on various recruitment websites have attached the term 'architect' as a trailer to almost all senior technical job functions.
At the top of the hierarchy is the enterprise architect - one who is required to ensure that he or she encapsulates all areas of business systems architectural knowledge.
The first question one asks is, what is an EA? There are numerous definitions of the EA. The definition I like to use is that of 'an individual or team who are deemed to understand the end to end horizontal and vertical technology components, processes and flows which make up the enterprise's business information systems'.
The above definition does not clarify the day to day role of the EA, but does provide the scope of the role.
EA's spend a majority of their time actively involved in what I call the 'architectural process' i.e. the rules that encapsulate the creation, maintenance and governance, where governance relates to the enforcement and policing of the conceptual models (abstraction layers) & systems maps.
The tasks associated with creating and policing target architectures require a set of individuals with a wide array of skill sets that have evolved and matured over several years. A question that often arises especially in instances when the architectural team has focused purely on a conceptual target architecture (discussed below) is that of: 'Why as an organisation do we require an enterprise architecture team?'
If the above question is raised, then both the EA and his team are on a downhill slope. How can this question best be avoided? The answer is simple - ensure that the enterprise architecture is clearly defined, documented and marketed to the organisation and that it is constantly aligned to the strategic goals and objectives of the organisation.
So we now know what an EA is, we know the scope of his / her role. Now the question to address is 'what are the attributes that the team should have or acquire'? Hence, the question we address in this paper is 'What are the contributing characteristics and attributes that make for a good EA?'
It can be argued that an EA must possess the same notional qualities of a master chef i.e. one who understands individual ingredients (technology components) together with the impact and use of these ingredients in varying quantities. An individual who can align ingredients to exploit a wide variety of tried and tested recipes / cookbooks (Frameworks).
As an EA, my focus in the early stages on a project is one of producing conceptual models that illustrate complex problems by filtering out non-essential details in essence making the problem easier to understand. This is assisted by exploiting various notational modelling tools (UML, BPML etc).
Practicing EAs seek to segment complex problems into manageable components and exploit various architectural principals, for example, that of the 'separation of concerns' and not just at the software component layer.
This segmentation is supported by the concept of architectural views where the initial focus tends to be on four vertical strands of decomposition (infrastructure, data, application and business process modelling). Where:
- Infrastructure relates to the physical components that make up the enterprise systems i.e. the tangible assets (Data Centre Components, Servers, Routers, Network devices & topology, protocols etc.)
- Data encapsulates elements such as repositories of information held within Relational/Object Data Management systems and the extract, transform and load mechanisms deployed within the architecture.
- Application refers to the executable software that performs the necessary functions and process conversions on flows of information. The application domain also focuses on concerns such as the interaction, integration and interface between systems in the enterprise and attributes such as state management components.
- Business process modelling seeks to automate business processes through the creation, maintenance and validation of conceptual models using various tools and execution languages.
The use of architectural patterns e.g. the Model View Controller pattern (used in Web presentation) provides an example of how the architects can reuse components and thus reduce effort.
All of the above views can be decomposed and elaborated yet further, however the goal of the EA is to understand, both the concepts and in many cases the supporting technologies.
A simple analogy that has been used on numerous occasions is that of geologists and the eco system - as an architect one must maintain a macro view (look at the planet as a whole). However, you should be in a position to drill down to micro components, continents, countries cities and yes, even the motorway network of the country.
Figure 1 - The Macro and Micro skillsets.
Figure 1 highlights the one set of views that the EA must understand. Emphasis must be placed on maintaining a macro view but ensuring that micro components are fully understood by the team as a whole...
But this is not the end of the story. Above we have advocated that the EA must maintain a macro view of the technology deployments and business processes i.e. a deep understanding of the 'current components of the production architecture' but he/she must also understand both the 'transitional' and target architecture.
Transitional Architecture (TArc) can be defined as the intermediate state between the current and 'to be' target architectural system states.
Understanding of the TArc can only be achieved by working with the business and project managers to understand the systems that will be deployed in the short-medium term which may affect the systems landscape. Examples of which are Commercial Off-the-Shelf (COTS) packages that exploit specific systems frameworks.
Understanding the TArc allows for the provision of non-compliant products e.g. if your organisation wishes to adopt a J2EE compliant target framework, but if there is a business requirement to purchase a COTs package that exploits the .NET framework, then you as an EA must ensure that this is captured and reflected in your technical road map.
Target architecture (TArg) involves understanding the current production environment, the current and future business processes and the TArc are some of the qualities that an EA must possess. However he/she must have the ability to define and ensure that the above remains aligned to the target architecture.
Figure 2 - EA Matrix.
For illustration purposes Figure 2 highlights, what I like to call the horizontal strands, an architectural grid, which seeks to align architectural entities (grey clouds) onto a simple matrix. This matrix can be used in architectural workshops to plot, at a high level, a snapshot.
The matrix in Figure 2 can also be used to determine the strengths and weakness of the EA in a simplistic graphical way during an evaluation period.
EAs must possess many qualities. These qualities are not just constrained to technical abilities; however it is important that an EA has a solid understanding of enterprise technical components.
EAs must encapsulate many attributes, as on a daily basis their role will be subjected to many architectural forces a sample of which are as depicted in Figure 3.
Figure 3 - Architectural Forces.
The EA must consider architectural forces which encapsulate the current and transitional system states, to ensure he/she delivers a structured agile framework to support target goals of the enterprise.
In summary, as the end-to-end technology becomes more and more distributed and complex in nature, a special team or individual is required to manage the 'technical road map' for organisations. This team, which we refer to as the enterprise architects, who will become more and more prominent in the organisation.
The EAs must be hybrids who have evolved over a period of time and have worked in different operational environments allowing them to have gained a wide range of technical exposure.
The EA must have both the strength (political) and ability to police and realize a technical transitional and target architecture, which can only be done by understanding the macro and micro technology components together with architectural frameworks, best practices and patterns that allow simplify a smoother transition from concept to reality.
Questions at an EA interview
When interviewing EAs I have found that they are either bias towards application or infrastructure components.
So to help you understand your EAs capabilities I have listed four simple questions you may want to ask a potential EA at their interview:
- When mapping a relational database to an object relational database why is the object ID significant?
- In the simple network management protocol (SNMP) configuration, what is a management information base (MIB)?
- What is an architectural pattern?
- How would you capture, define and manage a target EA in a turbulent environment?
