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, the term 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 essential domains. 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 and that provided some key lessons 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 start 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 while we professionals are struggling with the reality of the effort. As architects we are typically tempted to quickly delve to the next level down where we end up with incredible amounts of detail. Much of this may be unnecessary but we have been taught to go there by trade, and 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 and whose semantics are confusing ad inconsistent. It is easy for efforts to die here due to the perception that there is little of business value quickly generated. If we are diligent, and 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 that we now have some understanding of it. We may not be able to explain it very well at this point, 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 straight forward 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 quickly 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 achieve perfection. Perhaps that dictates against everyone becoming an architect or business designer but this Column will try to provide help.
The Business Architecture Landscape
In this Column, I will lay out a set of principles 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 approaches and extends them into a comprehensive view which 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.
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.
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 just one purpose.
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.
Organization Structure is Just a Domain: Domains are associated to the organization for which 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.
An Abstraction: Business Architecture is by nature a simplification of reality, and compromises will have to be made (remember the George Box observation earlier).
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 to accomplish than you think.
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 BPMN2.0 is not suitable for a Process Architecture depiction. It may be required at the specification level much later in the journey however. Traceability among levels is still essential. Remember there must not be any orphans.
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.
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.
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 such as 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 shown 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 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 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 are included because they are needed to attain a specific IT goal. We see particular approaches if the architectural leaders are attempting to establish a Service Oriented Architecture for IT service reuse. Concepts perceived as unnecessary to that particular purpose are often ignored 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 come as 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 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 make 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 the 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 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 building 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 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 in 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 focusses on business capabilities as the primary organizer of what's needed to make the business work. My experience suggests that some perspectives could be enhanced. 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 motivation for its managers. In so 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 shown 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, 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.
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 purpose is to define the components and connect them 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. 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. It addresses the Policies and Business Rules to assure that optimum decisions are made in those processes and to change the ones that are sub-optimal. It examines and changes the Organization Structure and the incentives of the positions in it to determine the changes required to provide the appropriate goals of each organization traceable to the outcomes of the processes throughout the various parts of the organization. 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 toward blending both physical and virtual work this domain will sustain its relevance. 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. 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 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 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
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.
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 which 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 more easily workable. Each of these will be described and illustrated in upcoming Columns. I will reinforce the Business Architectural principles as we go. The whole approach will be disected and put back together again to accomodate 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.