This month I am initiating a regular column on the topic of Business Architecture.  This sounds like a daunting task, wide open to anything that one may choose to talk about.  On the one hand, that accommodates diverse views but on the other it raises the issue that there are many narrowly-focused camps and professionals, each with its own view of what a Business Architecture should cover.  The opinions are many.

My perspective will strive to be a business one, not one that focuses on sub-topics such as the enabling technologies in isolation of the other domains that are essential.  A Business Architecture is a model; perhaps the most complex one we could imagine in business since it should cover all aspects of the whole business including how it runs day-to-day as well as what must be changed to keep it relevant.  Joe H. Ward and Earl Jennings said in 1973 that "models are idealized in the sense that they are less complicated than reality and hence easier to use."

This may be true, but our Business Architectures are still multi-variant and have many interdependent parts and are still complicated by their very nature.  Their many interacting components impinge on one another in mysterious ways that the architect must somehow unravel.  It is an impossible journey for those who crave perfection and indisputable detail.  The good and the bad news came to us courtesy of George Box in 1987 when he said that "All models are wrong but some are useful," and that is where I plan to sustain the focus of this column.  I will strive to be comprehensive and yet as pragmatic as possible, bringing useful experiences and insights gained from over 100 business-oriented efforts that I have been involved with that provided some key learnings about business design and architecture.

The Idea Behind this Column

A number of years ago I developed a simple two-by-two matrix of the challenges we face as architects.  I called it the Burlton NICE model.  It has kept me focussed on the goal as I learned anything new or took on any new venture.

We usually initiate an initiative in the Naïve state, where we and others do not have a lot of detail about the effort (in this case, Business Architecture discovery and design), but we are characteristically delusional — or one could say optimistic — at the beginning.  It does not seem that it should be all that difficult.  Clearly we do not understand much and, with all due respect, many executives can find themselves staying in this mode for long periods of time and wonder why things are taking so long and costing so much, as we professionals are struggling with the reality of the effort.

As architects we typically are tempted to quickly delve into the next level below, where we end up with incredible amounts of detail.  Much of this may be unnecessary and we have been taught to go there by trade, but we can quickly become overwhelmed knowing that we still do not know enough and that it seems Incomprehensible and impossible to communicate to others.  We still have a low level of understanding despite a lot of work.  Symptomatic of this level is lots and lots of detailed diagrams that are missing interconnections, whose semantics are confusing ad inconsistent.  It is easy for efforts to die here due to perception of little business value shown soon enough. 

If we are diligent, survive long enough, and work even harder, we will start to make sense of the mess and realize that what we have now is Complex but we mostly understand it.  We may not be able to explain it very well yet, but we are confident in our understanding of what is happening.  As Isaac Newton once said "I can describe Gravity to you.  I just can't explain it." 

For us to be truly successful we have to move upward in the grid by simplifying it and learning how to articulate it in a straightforward way.  As my grade-12 math teacher often said to me, "Your work proves the theorem as requested Mr. Burlton.  Now take it away and make it Elegant."  To me that meant it should be simple yet powerful.  Newton's Law of Universal Gravitation and Einstein's mass-energy relation are examples of Elegance, with incredible power derived by each brilliant scientist after a lifetime of searching.

This highlights the challenge we face as Business Architects.  We want to have sufficient knowledge but cannot go as deep as may be desirable because time, cost, and expectations dictate against it.  We have to be comfortable with a level of uncertainty and obscurity, and not be seduced into going too far before coming back for validation.  We have to learn fast how to see through the mess and abstract more readily.  We have to be comfortable knowing we can build greater detail and understanding iteratively over time.  Remember George Box's words:  "All models are wrong but some are useful."  Our aim is to be useful, knowing we will sometimes not get it perfect.  Perhaps that dictates against everyone becoming an architect or business designer but this column will strive to help.

This Article:  The Business Architecture Landscape

In this article I will lay out a set of principles to start with for Business Architecture and examine some popular architectural approaches that are available in the market today.  In upcoming months I will reveal, and then delve into, a model that uses various aspects of these and extends them into a comprehensive view that I hope you will find both elegant and useful.

A Set of Starting Business Architecture Principles

Most of the illustrative Business Architecture paradigms I will present in the subsequent section have something to offer to business executives and professional change agents alike.  I believe that, as a foundation, the following ten characteristics are critical in evaluating which combination of frameworks and methodologies will be best suited for you.

1. Clear Business Scope:  The business can be bigger (a set of organizations with a common mission) or smaller (a part of a company) than an organizational entity.  Regardless, the scope must be well defined and commonly understood.


2. Contextually driven:  The Business Architecture must be purpose driven, serve outside stakeholders, be strategically traceable and business performance motivated.


3. Comprehensive Domains:  All critical architectural domains of the scoped business must be covered and aligned, not just ones of particular interest to a specific professional group.  Associations among domain components are as important as the domains themselves.  A Business Architecture is not for one purpose.


4. Associate, do not Integrate:  Relationships among architectural domains are not hierarchies; they are associations.  The Capabilities and the Business Processes and the Business Rules are linked through many-to-many associations, not as sub-components of any one to the other.  Hierarchies may exist within a domain.


5. Organization Structure is Just a Domain:  Domains are associated to the organization for whom they are relevant — for easy change — and not built around a specific organizational unit or structure, which will surely change and make the architecture immediately irrelevant.


6. An Abstraction:  Business Architecture is by nature a simplification of reality and compromises will have to be made (remember the George Box observation earlier).


7. Elegant Models:  Business Architecture Models should be simple yet powerful and not overly complex (see the Burlton NICE model earlier).  Remember Einstein's famous quote "A model should be as simple as it can be but no simpler."  This will be harder than you think.


8. Notation Agnostic:  Business Architecture is not about driving a notation.  Implementation notations are rarely suitable for architectural concepts (recall Zachman's Rows and Columns and their intended communication audiences).  The detailed level of BPMN 2.0 is not suitable for a Process Architecture depiction.  It may, however, be required at the specification level much later in the journey. Traceability among levels is still essential.  Remember there must not be any orphans.


9. Semantically Consistent:  Every domain component should be described using a consistent semantic structure for its area of specialization.  The associations must have similar semantic rigor.


10. Journey, not a Destination:  There is no architectural destination.  It's a never-ending journey (a lifestyle change, not a crash diet).  Get going with just enough architecture, and learn how to evolve over time.

Model of a Business Architecture

The purpose of any business (or any organization) is to deliver outcomes of value for the core stakeholders of the business.  It has to strive to more than satisfy the product or service recipients, the owners, the staff, and even society.  It has to really understand their essential needs — stated or not — and provide a superior experience across multiple channels.  It has to do this while keeping a healthy relationship with all other external stakeholders, like various suppliers, regulatory bodies, and communities (to name a few).  The business is first and foremost defined by its success in its relationships with external parties.  Everything else should be aimed at achieving the desired outcomes at the border between your organization and those in your ecosystem.  Getting everything right to make this happen is a monumental task, with a lot of moving parts that must come together to form a total result.

The table above lists some of the Business Architecture components or concepts that need to be understood in order to have a comprehensive view of what needs to be optimized and aligned to required outcomes.  Clearly it would be extremely difficult to tackle all of these in one go.  A plan to build them up from the critical core set will take a lot of time to deliver, but that's part of the journey.  Paraphrasing John Zachman, "One day you're going to wish you had all of this."  Selecting the essential aspects to start with, and rolling out the remainder over time, is the only practical way.  Nonetheless, this list can be used to evaluate Business Architecture methodologies for completeness and integrity when you are making that choice.

An Examination of Some Popular Models

I will now survey some of the more popular methods that organizations are pursuing today for the establishment of a Business Architecture baseline.  It is clear that each of those that follow has a particular perspective and that not all aspects of the myriad of possible concepts are covered in each, begging the question, "What do you need from a Business Architecture?"

Many of the methods and models have a heritage in the information technology domain, wherein many architectural concepts typically in scope are included because they are needed to attain a specific IT goal.  We see particular approaches if the architectural leaders are striving to establish a Service Oriented Architecture for IT service reuse.  Concepts perceived as unnecessary to that particular purpose often do not make their way in because the advocates do not feel they are of interest.  The same can be said if the purpose is to establish and maintain an IT Portfolio Management capability where different concerns arise.

I am not trying to pick on IT here.  IT is often the place where the value of a comprehensive approach is recognized as having tremendous value.  The same can be said for those who are charged with Governance, Risk, and Compliance — or other programs that should also be based on an architectural foundation.  I am suggesting that we be cautious when labelling narrowly-focussed exercises as 'Business Architecture' despite the fact each may cover a small subset of the possible domains.  When this occurs it should be no surprise if those responsible for some other perspective, such as Process Improvement, do not find what they are looking for.

Osterwalder's Business Model Canvas

Alex Osterwalder's Business Model Canvas is not always seen as a Business Architecture framework.  However, for those who are striving to rethink the direction, strategy, and business model of the organization it contains many architectural components that describe both strategic intent (Vision, Goals, and Objectives as defined by OMG's Business Motivation Model) as well as strategy itself (Value Proposition, Mission, Strategies, Tactics).  It also covers some key Stakeholders, Activities, and Resources — all of which are key aspects of any robust Business Architecture that is striving to enable a different way of running the business. 

In my opinion, it is part strategy and part architecture.  It does not deal with all of the capabilities ultimately required for a comprehensive architecture.  It certainly does not deal with the interests of IT architecture, although its answers should be essential to making the right IT decisions and architectural choices.  It provides a good architectural start and, in that regard, serves the purpose of its planning and executive constituency.

Zachman's Enterprise Ontology

A useful way of thinking about the complex multi-domain and multi-perspective nature of organizations is to consider John Zachman's Enterprise Framework.  Enterprises have a set of domains and components that are composed into useful capabilities.

Each column answers a fundamentally-different question about the enterprise, and we cannot build a functioning business, or run one, without each aspect being somehow covered.  The classic six interrogatives (what, how, where, who, when, why) are the basis for this domain categorization.  So the question is, "What primitive domain models do we need to design and run a business?"  The answer is, of course, "All of them." 

The challenge is that even these domains are seen differently by different parties, with different responsibilities, backgrounds, points of view, interests, and personal motivation.  These domains also have differing perspectives depending on roles as shown in the rows of the Framework.  Strategists are not necessarily architects, engineers, technicians, or workers/performers, and all have their architectural needs.

When we put together the vertical and horizontal axes we can understand that each cell has two locators on the grid:  its domain (column) and its role (row).

Complete composite models at any row level are comprised of the primitive components from each domain in the row.  The components from each cell in the row are interrelated with one another in a 'where used' type of structure, describing a holistic perspective for enterprises or complete business designs.   To build anything of a complete nature all rows must be synchronized and each column must make sense with one another in that row (my view of alignment is integrity across a row).  In addition, to build anything that sees the light of day operationally we have to have all components in all rows for a column trace to one another as we transform views from top to bottom (my definition of traceability is integrity up and down the views in a column).

TOGAF

TOGAF is an architectural framework supported by The Open Group, which has as its main perspective the set of optimized requirements for Information and IT asset and capability management.  It is very popular with IT-oriented Enterprise Architects.

As can be seen in the diagram that depicts its main themes, it does have a specific component that tackles Business Architecture as the basis for IT Architectures.  Its lens on the Business Architecture is one that strives to capture what business knowledge is needed for taking the right IT design decisions.  It is not strongly focussed on processes or stakeholder value creation explicitly but rather on internal capabilities required to ensure delivery of internal assets.

Business Architecture Guild BIZBOK

The Business Architecture Guild's BIZBOK provides a rich body of knowledge concerning many of the aspects of internal capability for Businesses.  It is not as strong in the areas of stakeholder analysis and external drivers but focuses on business capabilities as the primary organizer of what's needed to make the business work.

Some perspectives could be enhanced in my opinion and experience.  It primarily misses the fundamental alignment strengths of having business processes as a concept of the first order.  It has no concept of top-down Process Architecture and, instead, treats process as one of the resources for capabilities to work, thus missing some key aspects of a full process architecture connected to the management system of the business and serving as motivation for its managers.  In doing so, it separates value chains, value streams, and processes where we believe there should be complete integrity and traceability among these for process management and stakeholder value creation reasons.

I also feel strongly that the depiction of the 'who, what, where, when, why, and how' aspects depicted in their main architecture graphic is misleading.  We believe, for example, that a 'capability' is a means to a business outcome and not an end of the business in and of itself.  We also believe that the 'organization' concept is not as stable as described in the body of knowledge document and that 'decisions' are not a 'when' since they are embedded in processes and constrained by policies and rules.  There appears to be a mixing up of the 'how' of the business and the how of business transformation which is itself a how.  It has a distinct IT EA flavor, pulling the other concepts mainly for that purpose and is not as business-outcome oriented as I would like.

Despite these seemingly harsh (and other) misgivings I may have, it is still a rich source of knowledge in many areas, and I do recommend it as a useful resource for Business Architects.

Burlton Hexagon

I developed the Burlton Hexagon twenty years ago to try to encapsulate the main aspects of what is required to ensure a complete set of attributes of a capability of a business process at any level of decomposition, from Value Chain to each level of process decomposition below.  Its intention is to define the components and connect them together in an aligned manner as opposed to developing disparate aspects of business solutions.  We use this concept to examine what works well and what does not, as the basis of root cause analysis, and also for the establishment of an integrated program of change and the estimation of what it will take to deliver it.

The focus of the hexagon is on attaining business performance goals shown in the bull's-eye, using processes as the measurable organizing/synchronizing asset.  The information asset and the knowledge needed and available in the surrounding ring are seen as key aspects of the processes that consume and create both of them.

1. It evaluates the strategic Intent and Strategy of the business and the processes that make it up.  It reflects the philosophy that processes are the value creators of the organization and the natural aligners of work and resources of various types needed to accomplish the purpose of the work.


2. It addresses the Policies and Business Rules to assure the optimum decisions are made in those processes and to change the ones that are sub-optimal.


3. It examines and changes the Organization Structure and the incentives of the positions in it to find changes needed to provide the appropriate aims of each organization traceable to the outcomes of the processes that pass through the various parts of the organization.


4. It examines the business Physical Infrastructure which, for many organizations that are capital intensive, can be a source of critical capability that is often skipped in typical business architecture approaches for whom capital assets are a large investment.  Given that today there is a strong trend to blending both physical and virtual work this domain will sustain its relevance.


5. The Enabling Technology domain is clearly seen as a critical capability in its own right, but it is better to see it as a part of the overall capability of the process in capturing and provisioning the required information for the process to function and the execution of the workflow to execute, monitor, and manage the work itself.


6. The sixth segment is one that is often overlooked in business design and business architecture.  The Human Capital requirements define key attributes of the staff and partner side of capability and, if ignored or neglected, they will surely come back to bite us in unforeseen ways.  The capability will be incomplete.  Having the required competency in our staff and partners is essential.  Having sufficient capacity or enough competence is essential, especially if the plan is to scale or the learning curve for new staff is long.  Having human resources with a shared motivation with that of the process outcomes (the bull's-eye), as opposed to conflicting objectives, is critical.  People with the appropriate behaviour needed for the process — individually and in groups — will make up the culture described in the organizational structure segment. 

The strength of the hexagon is its ability to establish aligned composite models to get the right work done in the right way.

Process Renewal Group/BPTrends Associates (PRG/BPTA) Model

The Process Renewal Group model, which is the origin of the BPTrends methodology, was originally formulated in the mid-nineties and has undergone continuing evolution for twenty years, to remain a modern way of designing a business.  It incorporates the best of the approaches described so far, combined with other ideas that have stood the test of time.  Within the past year it has been subject to a significant update to connect traditional and new ideas into a comprehensive Business Architecture framework and methodology as depicted in the figure below.  The diagram shows the main logic of the discovery and design process.

Process Renewal Group/BPTrends Associates (PRG/BPTA) Model 

Future Articles

Future articles in this column will deconstruct the components of the PRG/BPTA model and delve into its various domains.  They will also address related concepts that are part of each of the domains shown.  These will be supplemented by a set of techniques to enable the methodology that we have found to be useful in numerous efforts to make each domain easier to make work.  Each of these will be described and illustrated in upcoming articles as part of this column.  I will reinforce the Business Architectural principles as we go.  The whole approach will be dissected and put back together again to accommodate the complex nature of the real world and provide an elegant way of describing business design to optimize it.

That's the way I see it.

# # #