The Skeptical Architect – September 2011

We think that there are a multiplicity of architectural perspectives. In our May segment, we made the assertion that business and IT architecture are not the same but that IT architecture is contained in the overall architecture, which we called ‘Organization Architecture.’ We introduced some definitional distinctions we have seen about ‘architecture’ today. This time we would like to go a bit further and assert that an organization consists of a collection of architectures that are inter-related. The need to have one all-encompassing, current architecture may not be a reachable goal. The examples below indicate why.

A starter taxonomy of architectures:

We suggested a starter taxonomy for architecture discussion (Figure 1) in our May article that included a basic assertion that an organization architecture (for want of a better term) is made up of more than one architecture:

Figure 1: Starter Taxonomy for Architecture Discussion

We would like to point out that there are several different architectures and layers of architectures that come under the heading of ‘other.’ In fact, the IT architecture and process architecture are part of a broader picture.

A framework for business architecture:

The layered architecture approach:

Architectures exist that are layered in terms of scope in the organization. Experiences with business intelligence, reporting systems, performance management, balanced scorecard and related strategy mapping require an architecture that is results measures based. This type of architecture is found on the group and corporate level. It also includes an operational part that represents any federated services offered on those levels.

Each organization utilizes different viewpoints that are part of the normal operations of the organization. Figure 2 profiles each perspective from which an architectural reference can be drawn. They include  the business environment, the perceived market needs, product / service architecture, the process architecture, and supporting architectures.

This is best illustrated in Figure 2.


Figure 2: Architecture Perspectives

Notice where the process and IT architectures are placed. This does not in any way diminish the size or importance of an architecture type but only places it in relation to other architectures. In fact, if an architect is working at the group level, they may use the operational perspective to develop an architecture for the federated component.

This leads to some interesting observations:

  • No two architectures are alike

  • There are more architectures than we would like to admit

  • These architectures fit together in some manner

  • An organization can have all the architecture types in one business or organization unit depending on the scope

  • The primitives are the same on each level but the emphasis is different. For example:
    • On a group level, the architecture will focus on measures and the processes that deliver the measures. This view is group results-oriented with a relationship to one or more operation architectures.

    • On the corporate level, the emphasis is on strategy mapping, impact assessment of structural changes, influence indicators (outside the organization impacts) and results orientation.

    • On the operational level, the emphasis is on execution performance and the impact on results indicators.

The business process architecture is a descriptive representation of the way an organization operates and may include various categories of the enterprise context that are shown in the upper right corner of Figure 2. It provides a reasonable facsimile of the way the business runs. The primitive components or categories of the organization are well known and consist of the usual perspectives, such as organizations, locations, business processes (actions), decisions, systems and so on.

Additionally, the usual relationships exist, such as the business functions that need to be performed by the people who do them; one-or-more physical locations in which the functions are executed; different business processes (a hierarchy of actions described as verb-object pairings, such as create market, sell product, install product, and provide service) being run; and various policies, practices, rules and decisions being followed by people and systems. An operational architecture shows the many relationships that play an important part in the successfully running the organization.

But, let’s make sure the different architectural representations are clear. For example, process enablers have various architectural representations. Particularly, it should be noted that:

  • Information Technology (IT) architecture does not represent the business architecture

  • IT architecture only represents the digital part of the architecture

So the IT architecture represents mainly the automated (digitized) part of the business and not necessarily all the technology in the business. Since the business process architecture is more inclusive of the overall behavior of the organization, it may contain references to elements of the IT architecture. Also, some decision-making tasks within the business process architecture are performed by the organization and are outside the realm of the IT architecture, whereas automated decision-making processes are certainly included in the IT architecture.

So, in this brief summary, the Skeptical Architect is suggesting a way to partition the architectural view of the organization in a manner more suitable for communicating to management what is important to them. And what is important to them is that you are doing the right things and are cost effective and/or profitable in doing them.

Share this post

Gil Laware

Gil Laware

Gil Laware is President/CEO of Information By Design, LLC, a firm who delivers consultative solutions for strategic, tactical, and operational management of organizations. He has over 30 years of consulting and industry experience with Fortune 50 companies He has experience in manufacturing, transportation, government, finance and banking services including business and IT strategic planning; business process management, redesign and improvement; data management; warehousing and business intelligence; enterprise resource planning; project management; manufacturing systems; and customer relationship management. Previously, he was an Associate Professor of Computer and Information Technology in the College of Technology at Purdue University, an Associate Director for Fujitsu Consulting, Manager of Data Services for Whirlpool Corporation, Vice President of Information Services for Franklin Savings Bank, held various managerial and consultative roles with the IBM Corporation, and was President of Management Support Systems. He also provides training internationally. Gil published with TDAN.com and has authored over 30 papers including a NIST chapter that discusses the gaps that exist in the manufacturing systems software development process. He served the DAMA International Education and Research Foundation (DAMAF). He may be contacted by email at gwlaware@ibd-us.com.

scroll to top