Enterprise Maps: The Evolution of Business Architecture

We all recognize that organizations are complex entities made up of various parts that have influence upon each other. A change to a portion of a given business process, for example, could have an unexpected impact upon another aspect of the business in a completely different area of the organization. While this could certainly be negative, if the relationships between the elements of a business architecture are well understood and documented, it could also be managed to deliver a positive outcome. Extending a business architecture in this manner transforms it into a “what-if machine” and represents the emerging direction for business architecture today. Overlaying information, application and technology relationships can further transform this into a three dimensional construct of connections known as an “enterprise map”.

Enterprise maps are powerful tools. They consist of a series of layers (business, information, application and technology) each containing a set of aspects or elements. Dark Star recommends the addition of a fifth layer – one dedicated to security. Security is more than technical safeguards. Job rotation, separation of duties, business continuity planning, physical security, security governance, operations security and compliance-related issues also belong to “security architecture” (and in fact, are all part of the domains of the International Information Security Certification Consortium’s CISSP certification). The addition of a security layer provides needed insight into the overall security posture of the organization – which can otherwise be difficult for business leaders – who are ultimately responsible for due diligence relating to security -- to understand.

Concepts or notions on each layer are "elements". For example, the Business layer might have elements such as roles, processes and outcomes (just to keep things simple). From identified relationships between elements on this layer, we would be able to conclude that Role type “r” is associated with the process "p" (the exact nature of the relationship would be detailed in a connection description) and that Outcome “o” is the process result.

So what can we do with this? Let’s assume that the organization that this map (partially) describes was considering a change to a given business process – perhaps even eliminating it (process "x") entirely. The Enterprise Map would show the impacts that change might have. Perhaps Outcome “o” contributes towards Product “p”. But Outcomes “a” through “l” also contribute to Product “p”. Now, we could see the effect that eliminating Process “x” would have. 

Relationships can exist between elements of the same layer or between the elements of different layers.