More rambling thoughts on Solution/Enterprise Architecture

What is EA?

This question, frankly, is the largest issue across the industry and thus the reason my initial response is such a mish-mash of definitions. Essentially, it comes down to a difference of opinion within the base premise of Enterprise Architecture:

  1. EA is an IT discipline
  2. EA is a BUSINESS discipline

What (mostly?) everyone does seem to agree on, however, is that it is based on providing a business outcome through governance and strategy.

I will tell you up-front, my personal bias is towards the second perception – ie. a business discipline. To my current state of mind, this creates two definitions of EA being:

Enterprise Architecture: Noun: “Enterprise Architecture is organising logic for key business processes and capabilities reflecting the integration and standardization requirements for the firm’s strategic objectives and operating model.”

Enterprise Architecture: Verb: Enterprise Architecture is the process utilised in the aim of making better enterprises.

The Building Industry Analogy

I have a penchant to return to the building industry analogy to describe the structural breakdown of an Architect from Enterprise back to Solutions, Domain, Technical and Engineer levels.

The Enterprise Architect is the City Planner. They’re looking to solve larger issues that will affect the total landscape. They consider the interactions of the entertainment zone, development, farming, residential and industrial zones. This will require a number of considerations – infrastructure, telecommunications, waste management, traffic management – and the broad range of areas requires that they cannot get stuck on the miniscule details. Thus, they need to consider minimum guidelines that will become the planning regulations (governance) for the city (corporation) to be followed by those that begin the implementation work. The EA has a BROAD knowledge base across multiple domains.

Solution Architects are Town Planners. Like the Enterprise Architect, they are focussed on managing the governance and strategy for a range of domains, however, they are focussed on a smaller level whether or not it is part of a larger Enterprise (City). Like the EA, the SA also has a BROAD knowledge base across multiple domains, though may still have some strong depth in key arenas as they often “graduate” from Domain Architects.

Domain Architects: These are cross-specialty multi-domain experts. Unlike the Solution Architect, they are often focussed on a range of complementary domains in which they have some DEEP knowledge accentuated by a BROAD base. In the building industry, these may be Architects who focus on Industrial Estates, Shopping Centres or on estate-wide water and utilities planning. In the world of Business and IT, we can consider these to be Industry or Portfolio Architects, Consulting Architects or simply Information System Architects.

Technical Architects: The draughtsmen of the industry. These are the people with the deep skills in a certain domain. They pull together the governance, strategy and requirements and develop an implementation design that meets the unified scope. A Data, Applications or Infrastructure Architect all meet this definition.

Engineer: Like in the building industry, we often make use of specialists to determine the finalk design meets the specifications for a particular domain or speciality. These are the people who do the detailed work on the plans. This can include DataBase Architects, Firewall Architects, Design Engineer or Engineering Architect.

see a model I tried to represent a while back

Why do I blather thus? Because, in my world view, an EA should be able to take up the reigns within any industry and utilise their skills, knowledge and abilities to make use of any of the skillsets of the “architects” for that industry.

Technology is not simply IT.

On EA vs SA and the debates over Frameworks

If an EA team is concerned with the enterprise-wide optimisation of business systems, then some form of understanding is required – a framework assists in the processing of that understanding. A framework, after all, is “a basic structure underlying a system, concept, or text.” Essentially, it matters not if you utilise Zachman, PEAF or some strange mystic runic system as long as it is consistent, communicable and functional.

If it assists in improving business systems whilst ensuring management and stakeholders understand the impact so as to commonly work towards minimised risks and maximised opportunities – then does it matter? In the end, the goal is to improve the enterprise and the measure of that should be in the reduction of complexity and increase in agility?

TOGAF may not be a “an all-out, wholehearted, EA method” – however – it does lead the primary audience of the (related) craft towards it through the influenced accumulation and iterations of TOGAF from IT Architecture (back) towards Enterprise Architecture. In fact, I would not be surprised to see the future iterations begin to incorporate elements from other frameworks to bolster it towards TOGEAF.

To iterate, if the process you are undertaking, regardless of framework utilised, is tactical, then it is a SOLUTION Architecture. If the process you are undertaking is far more abstract, defining strategies, policies and standards for cross-organisational and enterprise wide strategic value, then it is an ENTERPRISE Architecture.

The knowledge path for EA

So what is the path for an EA? I’m still nutting that one out and has been part of the overall discussions and debates that surround the process of the restructuring a curriculum in the corporate university for the training and guidance in the graduate programme.

My  personal view encompasses that TOGAF should be part of that learning path for all aspirational EAs and should perhaps even be incorporated into the MBA. I have often used my analogies and “alternative technology examples” in discussing and teaching the ADM – it offers a better grasp of the framework for thinking beyond one’s own responsibilities and in considering the larger enterprise and stakeholder landscape.

However, as stated above, TOGAF is still very much a tactical, change implementation focussed Architecture Framework as essentially, you can break up the ADM into 4 core groupings – Getting the vision right & the organisation committed (Prelim & Phase A) – Aligning the Architecture (B / C / D) – Managing the Implementation/Transformation (E / F / G) – Manage & Maintain the Operations (H / Req Mgt). It is thus thoroughly necessary to ensure a range of aspects – including unified taxonomy and standardised processes.

Does an EA need to follow a layered approach? Should they be exposed to the Delivery or domain architectures? What should they look like if that is the case? Would people agree with this as a basic map and overlay view?

Is this the Architecture layer map?
Is this the Architecture layer map?
Layered Skillsets and capabilities?
Layered Skillsets and capabilities?

Most of the areas of additional learning arenas that come into play towards discussing the EA training path – such as skilling up with the BABOK or PMI – really are just boosting or rounding out the skills within the ADM, they aren’t really furthering the skills and mindsets towards the enterprise wide strategic value element of EA thinking.

So what assists with that element of thinking and skilling up? What should be part of the toolkit for the aspiring Enterprise Architect?

Author: xntrek

Just an awkward, politically incorrect, maladjusted, ire-filled, eccentric curmudgeon and decrier of lawn trespassers.