Business Architecture: The Missing Art/Science on the path to Strategy Execution
I have been told more than once, that Enterprise Architecture (EA) is a waste of time. I’ve been told that by bosses, by clients, by colleagues and by developers. I can understand that some people don’t understand the role that Architecture plays within a company — especially business people. But when a CTO or a CIO tells you this, you have to wonder how they came to be in their position? Are they the owner’s niece or nephew? Do they hold secrets over the CEO? Perhaps they just look the part. They obviously did not get it from their intelligence and capabilities.
EA is critical thinking on a grand scale. It is the practice of connecting the dots between strategy and the tactical details. It is the art of defining a path to the future for the business, through technology.
Many at the C-Level in IT do not understand what EA is. They think of it as Solution Architecture at the enterprise level — this is evident when you look at job postings for Enterprise Architects that are focused on providing a solution. The EA role is actually much broader than that and has a much more significant impact. EA does the mundane, such as documenting and maintaining the architectural state. EA does the necessary, such as establishing the protocols and governance around technology. And EA does the powerful, such as aligning the execution of technology with the corporate strategy.
Following The Open Group Architecural Framework (TOGAF), EA has several domains, including Business, Applications (which includes Data) and Technology (servers, networks and other deployable items). Of these , Applications and Technology architectures are the most well known. Business architecture, howeber, is often not implemented in many organizations. That is a shame, as it is an essential piece to EA — it is what allows the technology to be put in place to implement the enterprise’s strategy.
TOGAF and its Architecture Development Method (ADM) begins with business architecture. This is where you define the architecture of the business, from the organizational model to the roles to the business processes. Some may say that this is the realm of business and not IT. That is not incorrect. It may be that EA should not be wholely a part of IT, but report to the CEO or COO. EA is a collaborative effort. It may not have the responsibility to define organizational structures or business processes, but it has a need to document the organization and its processes. It also may bring structured methodologies that can be used to help define the business architecture. Some of the specific services that EA can bring to business architecture includes:
- Maintaining the Enterprise Architecture Repository (EAR) — The EAR is a central repository of all EA data across the architectural domains. Ideally this is a data-centric repository, rather than document-centric. This allows the ability to query the repository, allowing for traceability and reporting.
- Providing Strategic Alignment Services — Strategic alignment can come in many ways. It can include performing strategic analysis or taking a defined strategy and defining a capability roadmap. Capabilities are defined abilities that the business has or aspires to. It is roadmapped to the strategy. For example, a capability may be to quickly achieve Return on Investment (ROI) on new storefronts within a defined period of time. It is roadmapped by placing it into a timeline, typically no more than 18 to 24 months into the future.
- Defining and Documenting Business Processes — Business processes should start with cataloging the business processes and then proceed to elaborate the business processes. A well known, and widely used, format is Business Process Model and Notation (BPMN). This notation should identify steps in a business process, roles involved in the process and applications involved in the process. Ideally the BPMN can be stored as data in the EAR (not as a document).
These preceding items are inputs to the primary planning tool of EA:
- Developing the Technical Roadmap — The technical roadmap provides the path forward for the IT organization. It defines when and where IT needs to act in order to execute on the strategy.
This service provides the critical link between business and technology. As noted, the three inputs include the EAR, the business process definition and the strategy alignment services. The EAR, provides the current architecture state — without it you don’t know what needs to change. The business process definition defines the tactical changes that need to be made — current and future state definition, which includes defining the changes in roles as well as systems involved in the business processes.
Get Jake’s stories in your inbox
Join Medium for free to get updates from this writer.
Within the strategic alignment function, utilizing the capability roadmap, strategy is brought to the picture, ensuring alignment between strategy and technology execution. EAs develop a technical roadmap, ensuring the technology is in place to achieve the capabilities. For example, utilizing the capability example defined above, the data to calculate ROI needs to be available. This includes developing the BI systems, data integrations and other technologies to report the Return on Investment.
Developing the Technical Roadmap based on the capability roadmap also solves another common issue in organizations: The focus on tactical features. Development resources are finite. Product teams are working with the business units and they are often reactive to the business demands. Some product organizations implement Lean Value Tree or other methodologies that can relate features to strategy. But the capability and technology roadmaps add a layer of time to the analysis that is critical for execution of strategy. Lean Value Tree also relies on “Bets”, along with mission and strategic goals. Bets rely on assumptions, which may be of varying quality. While there is value in this, I find this analytical method to be lacking intellectual discipline.
On the otherhand, capability and technical roadmaps are more rigorous in their approach. Strategy is mapped to the capability roadmap and this to the technical roadmap. However, the capability roadmap is not static once it has been defined. The technical roadmap tempers and provides feedback to the capability roadmap. For example, when developing the technical roadmap it may come to light that a technology will take eighteen months to be put in place, while the capability was defined to be in place within twelve months. The capability needs to be adjusted. This could be as simple as pushing out the capability by six months or it could be breaking the capability into smaller components.
There are other inputs as well — budget, organizational model, business partner capabilities, the dependencies and relationships between technologies are all elements within the roadmapping. The other big element is the strategy itself. EA can have a role in developing strategy, although this is not common. EA has tools to perform strategy development, in particular I like the Archimate 3.1 Strategy and Motivation elements which map resources (assets), capabilities, value streams and courses of action. This is a topic for another article.
Enterprise Architecture, ultimately, provides the most value when it is engaged with business. But how does it do this when it is embedded in IT? There are two paths, as I see it. The first is to elevate EA to report to the CEO or COO. In enterprises with a strong hierarchy this can be beneficial, but in more agile organizations this may not help. In this case, a second approach may be better. Defining EA as a cross-organizational entity may be a better approach. The Business Architect does not need to be placed within IT. They can be within Product Management, individual business units, report to the C-level or even Finance. This latter approach, I believe, is the future of EA. It aligns more with a collaborative, agile approach.
EA, unlike solution architecture, is broader in scope and provides immense value in supporting strategy execution in both business and technical realms. Many technology executives don’t see the value in it, because they like to call the shots. Their own hubris interferes in their recognition of the value of structured analysis — they continue to use heuristics and other not structures decision-making tools that can do as much damage as well as good.
Enterprise Architecture brings structure and organization, drawing clear lines between strategy and execution. Strategy and execution are both important, and connecting the two though strategic execution is essential for success. This is not always foolproof — things change (such as uncontrollable changes to the business environment such as the Covid-19 pandemic). But the structured methodology is, hands-down, more effective than a by guess and by golly approach. The EA function has the mapping of strategy to execution as a prime concern and provides significant value to the organization through these efforts.
