Conclusion: Business architecture is poorly served by IT-centric enterprise architecture teams. While EA teams have the skills to establish detailed technology architecture, they lack the knowledge and understanding of the higher-level business activities that the technology is supporting. Meanwhile business experts who do have an innate understanding of the business landscape lack the skills and tools to create high-fidelity business architecture. To create a complete Enterprise Architecture, organisations should consider splitting responsibility between business and IT areas.
Observations: The terms business architect and business architecture are often used very loosely. In a strict sense business architecture is the subset of an enterprise architecture that deals with the structure and behaviour of organisational assets in support of a business operating model. These organisational assets are generally the non-IT components such as business processes, roles, rules, knowledge, events, locations, services and products.
Most enterprise architecture frameworks (such as TOGAF and Zachman) include the business architecture elements as part of the encompassing enterprise architecture. So in theory, business architects should be members of the enterprise architecture team, just as the information, application and technology architects are.
This is rarely the case.
In IBRS experience, virtually all enterprise architecture teams report to the CIO, normally through another senior IT executive, and exclude important business architecture elements such as business processes, functions, services and products. At the moment many organisations are restructuring IT around a “design, build, run” model and EA is typically positioned in the design stream – alongside areas such as business analysts, business process modellers and usability.
The term “business architect” is a title adopted by people from various areas within an organisation, both inside and outside of IT. These are often senior business analysts, process modellers, strategy areas or transformation consultants, who are outside of the EA group, but use the term “business architect” to indicate a more strategic nature to their work.
The challenge with these self-anointed “business architects” is that while they generally possess immense subject matter expertise and extensive networks with key stakeholders, they lack the structured methodology, or systemic approach to their work which would qualify as an “architectural” approach. They often work at the conceptual or business case level, and are generally unaware of the established discipline for managing business architecture found in enterprise architecture frameworks.
It is important to distinguish between these “business architects” and the function of “business architecture”. IBRS is not aware of any successful formalised “business architecture” teams who exist outside of IT and manage the discovery and definition of business architecture using accepted architecture frameworks and tools that are integrated with the related IT architecture. Business architecture can be found implemented in a number of ways:
Some organisations have business architecture functions that operate within EA teams but do so in a limited fashion, and lack the skills and knowledge to craft a complete and accurate picture of the way a business operates.
Some have business architecture functions that sit alongside EA teams within IT, but are loosely connected, such as business process modellers, rules analysts or service management functions. The information these teams create and manage is often not integrated with the EA view.
Some have business architecture teams that sit in the business but manage information in an unstructured manner in isolation of the IT EA and other groups.
Running business architecture out of the business: Enterprise Architecture has largely emerged from IT and is still often perceived IT-centric activity. But the true scope of Enterprise Architecture is much broader than just the IT elements of an organisation. However given EA has been driven by IT, not surprisingly, most EA teams tend to be much stronger on the technology side of enterprise architecture. The business architecture elements are often ignored, or pushed out to separate teams, such as business process modelling or business rules. Rarely are all the business architecture elements managed with the same care and attention as the technology and application areas.
Ideally a business architecture team would sit in a business area, report to a business executive and manage business architecture elements using an established framework and information repository that is shared with (and protected from) their IT architecture colleagues. They would have a separate governance process that is accountable to a single board level executive. They would act in close concert with IT architecture but be logically separated. In these situations the role of an EA framework clearly delineating between what is business architecture and what is IT architecture and how they relate is essential.
The diagram below shows how the enterprise architecture function could be split along business and technology lines.
In this situation the interface between business architecture and technology is tightly coupled around applications and information. The governance mechanisms of business architecture and EA would need to be carefully synchronised around these dependencies. A set of principles would need to be established and agreed between the EA and business architecture governance bodies to promote coordination and cooperation. An organisation with a low governance maturity would struggle to implement such a structure effectively.
The diagram below indicates a generic governance structure that could support the operation of a dual business / IT enterprise architecture strategy.
Key to this structure working is ensuring that the information managed by the business and IT areas is unified in a single repository with consistent architectural principles and modelling standards applied across the two areas. The responsible senior business executive must have an appreciation for a systemic approach to business architecture and recognise the importance of the activity as a management discipline.
Understand whether the Enterprise Architecture team is effectively supporting the business architecture view. To do this have business stakeholders validate selected models of business functions, services or processes. Decide whether they are an accurate and meaningful representation of the business operating model.
If not, consider whether situating the responsibility for business architecture under a business executive would enhance the completeness and accuracy of the enterprise architecture. For this to be successful ensure the following pre-conditions are met:
A mature governance culture exists within the enterprise
A responsible senior business executive is willing to take on the function, understands the value, and appreciates the nature of a structured, systemic approach to architecture definition and management of business activities
A unified set of information management tools is available to support the business and IT architecture teams in establishing and maintaining the enterprise architecture
Most critically, a business unit exists that has a purview across the entire organisation and does not form part of a siloed operation. If this is not the case, then the best place for EA is in IT.
Understand the transition plan for enabling business driven Enterprise Architecture
Initially groom business architects inside the EA team
Next establish a dotted reporting line from the EA team to the nominated business executive
Finally transition business architecture as a separate function to the new arrangements