Enterprise Architecture has evolved over several decades now. Initially incorporating the technical, looking at components, standards and interfaces to allow interoperation of programs, platforms, messages, files and technologies. Expanding to address application landscapes, data, security and processes. More recently addressing business issues, operating models and the contexts within which they operate. EA also has to engage with neighbouring disciplines such as risk and compliance, change management, programme and portfolio management and strategy.

EA has traditionally been divided into the BDAT domains, viz. Business, Data, Applications and Technology. Things like Security have been overlaid as “Cross Cutting Concerns” - i.e. they do not fit neatly into one of the domains, but have implications and concerns across several.

Given the depth of knowledge required for competence in any one of the domains, it is small wonder that different “turfs” have arisen where different bands of architects feel they have ownership. However, the real benefits and value of an enterprise view are often to be gained when we consider the holistic view of all the domains and how they impact and inform each other.

What is useful is to identify the “intersection concepts” between the domains. These may belong to one domain (and fall under the responsibility and jurisdiction of one kind of architect) but they are important for adjacent domains to create alignment and perform competent analysis. A strategy we have frequently adopted with good results, is to allocate concepts to a domain for ownership/update/maintenance, but provide visibility and relating rights to other adjacent domain architects. For example, an Application Architect would have jurisdiction over the concepts Application System, Application Service and Application System Component. Accordingly, she would be able to create, update and manage these instances. A business architect may have jurisdiction over concepts including Business Process, Organisation Unit and Offering (being a Product or Service). He may be able to see and link to instances of Application Service which support a given Business Process or Offering. The business architect might also have jurisdiction over the concept of Business Object (a conceptual data definition). A data architect might have visibility and linking rights to the Business Object and jurisdiction over the more detailed data concepts of Logical Data Collection and Physical Data Collection. These arrangements should be supported in a competent EA repository/tool e.g. EVA.

In this way each architect can maintain instances of the concept that they are responsible for while aligning with and linking their content and knowledge to that of adjacent disciplines. When an architect feels the need for an alteration of information in an adjacent domain (say the data architect needs the creation of a new Business Object), she would need to request this be done by the business architect. In this way collaboration and alignment is achieved. To see how domain intersection concepts are addressed in a production scale meta model, take a look at this related article and graphic (Inspired Holistic Architecture Language).

From a professional development perspective, it serves architects well to be interested in neighbouring domains and “look over the wall” to learn about them. This can be done by participating in other interest groups, attending webinars, reading articles and sometimes taking training outside of our own comfort zones. We can engage with adjacent architecture domains, as well as strategy, change management, programme management, enterprise risk management, portfolio management and system delivery. An architect who understands, at least at some level, the issues, priorities and challenges of the surrounding disciplines is far better equipped to have better conversations, provide meaningful deliverables to colleagues and to have an increased impact and delivery of value.