Essentials of Business Architecture: Retaining Business Knowledge: What do you need to know?

Introduction

This is the twelfth column of this series. Along the way, I have discussed many ideas, models and methods. In all of the Columns, I have presumed that we have or can gain some grip on the business knowledge that the various aspects of the business architecture are creating, or need to know. Implicit in this is the base assumption that we are not developing architecture components simply to conduct 'a project' or solve a single problem. The architectures are for the main purpose of creating a long-lasting, sustainable business advantage and ease of change. They will be helpful – even necessary – for a single-purpose change, but I contend that architecture should be about more than a transformation, since if we only focus on the movement to a new product, service or even a new business model without thinking longer term, then as soon as we finish a particular change we will immediately begin re-architecting all over again in the next transformation fire drill.

It is clear that we are leaving the so-called industrial age when we had the potential for long term sustainability in the market and are entering the knowledge age, where constant turmoil and short product and service time-in-market will become the norm. Drivers such as digitalization, agile, fickle consumers, new technologies, radically different and cross-entity broadened business models, social media culture, real time expectations, etc. are throwing old ways of doing things into the scrap heap. There is no evidence to believe this trend will stop or slow down any time soon, if at all.

It's clear that if we do not know what we have, then continuous change will be risky and potentially creating unintended consequences, making the expression, “the main cause of problems is solutions” a reality. Some approaches such as agile software development is helpful but not sufficient in and of itself to solve a multidiscipline problem. A bigger boat is required. One that will let us

  • be continuously relevant,
  • produce continuing value,
  • become constantly innovative,
  • exhibit marketplace adaptability,
  • be capable of perpetual business agility

The Framework

In several of the columns to date, I have mentioned the importance of a common semantic framework as the practice of Business Architecture has emerged and evolved in the three years I have been writing this column. As I have been applying the methods and techniques described, my teams have increasingly relied on the formal structuring of an architectural metamodel as the foundation of several other types of domain models. The overall Process Renewal Group (PRG) architectural framework has also evolved to be more workable and easier to communicate to practitioners. This is the latest framework graphic. In practice there are even more domains to consider.

figure 1

In the first column of the series, I intended to provide an overview of the business architecture field and introduce an overarching set of domains that we at PRG have been successfully using to classify and categorize issues of concern. The new version of this model (above) recognizes the iterative nature of the major phases of the development of a business architecture. The approach is certainly agile in nature, and the population of the knowledge required for each domain of interest can only really be well understood in the context of the others, despite the need to keep each domain independent in specification but interdependent in real use. Over time, with this set of business knowledge domains evolving and becoming more robust, we will be able to use knowledge of the domain components and their inter-dependencies in a value chain to enable rapid prediction of the impacts of change.

Underlying the Business Design Phase of the architecture is the model of business concepts that form the basis of business knowledge. In the last column I examined this model and looked at it as the foundation for the business processes needed to act on those concepts, the business capabilities thatare necessary to make the business work, the key performance indicators to assess the state of the business performance and, most importantly, the translation of what we need to know about( the information )to keep the organization alive. In addition to these critical architectural domain building blocks, the model of the operational business concepts provides a rigorous foundation for the structuring of business rules to be used in making business decisions. Knowing the essential elements of the concept model is the start of ease of change that is critical for establishing and sustaining business agility.

Other Frameworks and Inspirations

The idea of capturing and using architectural artifacts is not new. By exploring some of the most useful ideas we can see that business knowledge management is central to their success.

Zachman Framework

John Zachman's framework is broader than what is covered by Business Architecture. It's structure of columns defining the attributes of a business is comprehensive. Answering the fundamental six interrogatives of What, How, Where, Who, When and Why will provide what we need to know about the prime areas of interest in the business. Looking at how they interconnect with one another is the magic behind defining business architecture requirements. Taking a look at rows 1 (Executive Perspective) and 2 (Business Management Perspective) we get to the point that Business Architecture is trying to address. Looking at the perspectives in rows below (3 through 6), extends the idea to what Enterprise Architects and Developers – especially IT oriented ones – must deal with.

The value that Zachman brings as a thinking model, for example, is that Data is not Process, Business Managers are concerned with different topics from those of Technicians, a Capability is not a single concept but a composite of the other rows and that all primitive models (cells) are connected to others. Despite what one may think of the framework as an implementable architectural model, this separation and association of concerns and perspectives is essential to architectural thinking and reuse of concepts and thus critical for the management of business knowledge.

figure 2

Business Process Manifesto

The Business Process Manifesto (https://www.bptrends.com/resources/bp-manifesto/) describes the 'How' column of Zachman's Framework and its relationship to other aspects of business knowledge necessary to describe how the work gets done. One of the key aspects of this document is that there is a set of architectural (row 1 and 2) processes that connect to one another at the same level of abstraction and that every process has the potential for a more detailed description providing an increasingly focused look at the work itself. This is not to be confused with a different perspective provided by a different Zachman row. A technician's view is not a decomposition of a business person's view, although there should be traceability from one to the other. They are different models for different uses by different professionals. Decomposition does not move you down the page but into the page. This highlights the challenge in structuring the various model points of view that define the structure of the business knowledge to be discovered and re-used.

The manifesto also presents the issue that a business process does not stand alone when it comes to usability. Many of the other columns and composites are connected to the processes for it to work. Data (What) is created and used by processes, events (When) trigger the beginning of process work, goals and objectives (Why) guide and motivate performance, capabilities (a composite) enable the resources to do the work. There are many connections that we must know about if we are to be able to manage change.

Business processes are just one example. All other combinations of rows and columns are tethered to one another as well, and if we wish to change any, it would be helpful to know the impact on the processes.

Business Agility Manifesto

The Business Agility Manifesto (https://busagilitymanifesto.org/) is a call out to senior leaders and architects to put business agility as the raison d'etre of business planning and investment for the future. It presumes that business change will be perpetual and that the value of architecture and business design is to enable easy and fast change that does not introduce unintended consequence because we understand the implications of a change in anything on everything. It clearly states that its purpose is to provide an ability to modify dynamically the concepts and structures of the business itself, and that this ability necessarily must include the business knowledge to dynamically reconfigure implementations to continue business operations as business changes are formalized. It was developed in 2017 by a collaboration among John Zachman, Ronald G. Ross and myself, bringing a broad base of experience and in-depth history of dealing with the challenges that organizations are facing today. Based mostly on common sense – not common practice, it is a call for new strategies, criteria for investment and a longer-term view of our ability to survive and thrive, it specifically calls out business knowledge as the critical enabler for change and design decisions. It also recognizes the need for a knowledge base based on the structured knowledge concepts.

Business Architecture Guild's BIZBOK

figure 3
The Business Architecture Guild is a professional membership organization with the purpose of bringing clarity and consistency to the practice of Business Architecture. One of its distinguishing benefits can be found through the knowledge it produces in its BIZBOK. This substantial guide also addresses the business architecture world in terms of what and how a number of areas are defined and connected. Its areas are structured differently from Zachman in that they provide a mix of primitive (e.g. Information, Value Streams) and composite areas (e.g. Capabilities, Initiatives and Projects)– all areas of interest for Business Architects. Similar to the Business Process Manifesto, each can be decomposed within itself as well as in interconnected areas. To remain flexible we have to know about both the area as well as the interconnecting relationships. The BIZBOK, which to access you will need to be a Guild member, can be found at https://www.businessarchitectureguild.org/general/custom.asp?page=about.

Business Architecture Guild Working Groups

The Guild BIZBOK is a constantly evolving work. Twice a year some aspects of this reference are updated. The lessons learned and practices discussed are constantly moving forward. Within the Guild, there are a number of volunteer groups working within specific subject areas with some exchange across topics of interest. Each is grappling with how to best represent the evolving knowledge of business architecture. It is typical for these groups to assure reuse of knowledge definitions or to update when enhancements are called for. One group, within which I have been working, is the Business ArchitectureBusiness Process team. Knowledge areas and their interrelationships have been at the heart of the discussions. One of the main areas of discussion is the relationship among business capabilities, value streams and business processes – a challenge that architecture and process professionals have been debating for many years. Once all members settled on the concept that value is the central tenet, we were able to share a common process – value stream was the starting point that allowed process practitioners to keep looking for necessary capabilities and also allowed capability practitioners to search for necessary processes.
figure 4This has settled a knowledge problem and made it possible for methodologists to work in their own preferred way and still satisfy the same knowledge requirement. The diagram shows the necessary interconnections among the components as well as the connection to resources needed. Knowing the impact of a change in any one on the other areas is the secret for good architecture design, business agility and vendor tool selection. It must be reflected in the knowledge base structure – the metamodel.

This is just one example of the types of knowledge required and how the various aspects must be interrelated. This same determination is happening in many others.

OMG Business Architecture Metamodel RFP

A metamodel is simply a way to structure knowledge of a particular subject of interest. It is a concept model of the knowledge areas that must be known with consistent definitions of terms – like all concept models – but for business architecture and its relationship with other metamodels at the periphery. At the point of writing, the Object Management Group has received and is considering submissions received for the definition of a standard for a Business Architecture metamodel. The previous sections of this column clearly point to the need to have a set of common categories and relationships so that models can be shared and interchanged and so that Business Architecture professionals have a common language and can practice focused on common artifacts. At this point, the submitters are collaborating to reconcile differences for the purpose of putting forward one recommendation. All are committed to establishing a consistent structure that will serve all Business Architects and will also enable tool vendors to capture and potentially to interchange models among tools.

Being Practical

Clearly there is a strong argument to define the areas of knowledge needed to improve the ability to change. The domains and interactions among the areas, however, could be many and potentially unwieldy. I believe that organizations have to be pragmatic regarding what to go after. It is my opinion based on experience with many businesses that a core set to start with is prudent as opposed to going for everything. Time and maturity will help with the growth. I do not expect everyone will agree with my choices. The nature of your business may drive other areas, such as Business Rules, in a time of regulatory pressure for an insurance company.

Short to Mid-Term Domains

In my experience the three key starting areas are as follows:

  • Information
  • Processes / Value Streams
  • Capabilities

figure 5
The business concept model (Column 11) – sometimes called the business object model – is a foundation that must be present to derive these, of course.
These must connect to business value and the strategy to answer the question of why we do what we do and how we choose to invest our scarce resources for change.

  • Stakeholder Expectations
  • Strategic Intent
  • Business Performance

The result is that we can leverage our business architecture for best business value including sustaining the knowledge for optimum sustainability.

Change priorities

The two sides of the above diagram are used to make best choices. We can prioritize any of the information, process or capability domains and drag in the connections to the other two areas, assuming we know what they are. The choice will depend on your own practices, methodology and architectural culture. Nonetheless, all domains must be in synch when the final choices are made. There is no point prioritizing a capability change for process that is unimportant. There is no value in solely prioritizing a process without including those capabilities that just do not function sufficiently to support process performance. A combination approach is necessary in which the most value-added domain component is paired with consideration of the current performance gap. An earlier column covered the requirement to invest in the High Gain and High Pain choices of Information, processes and capabilities.

figure 6

Without the business knowledge of how each depends on one another, poor choices will be made, thus risking the ability to come to a total solution.

Tooling needed

It is clear that knowledge retention is a critical requirement for business agility. Despite all the prognostications that agile software development methods may not need it, nothing could be further from the truth. In reality if this knowledge of interdependent parts were available, I am convinced that agile teams would use it and do better work. The problem is that there is typically little commitment to sustain the knowledge as things change. This will always be the case so long as we are project based and not asset based – so long as we think only short term. A large part of the challenge is that we often do not have the knowledge base and tools to keep track of what we've got. Tools are essential. Full function and shared toolkits with strong impact analysis and “what-if ” capability is essential. With so many sources of input in so many knowledge domains, it is ludicrous to expect anyone or any group to keep it in their heads or even in static documents. Sophisticated tools such as QualiWare, BiZZdesign, IRIS, Mega, Trisotech, and if you are process centric, Signavio and Bizagi, to name just a few, are needed. With all due respect to Microsoft; Visio, PowerPoint, Excel and the like are not choices that can connect the dots and be queried.

Business Knowledge and Maturity

The current reality is that most organizations are knowledge-poor regarding Business Architecture and understanding the impacts of change. What we do have is frequently out of date and disconnected. It is foolish to think we can solve this challenge overnight. A journey is needed which cannot be skipped. I have seen many organizations try to go from low ability and maturity to become world class overnight. It does not work and the effort can meet with significant cultural and political resistance, not to mention the time required to gather and structure what they need to know. Achieving useful Business Architecture capability is a matter of knowledge, maturity and readiness. The following is one assessment of where you may be and how far you want to go. It may not be practical or possible to strive for level 5.

figure 6

Summary

Steven Hawking once said “The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge.” If we truly know where we are and what we have, we can chart a path to our goal of leveraging business knowledge. If we think we know enough about what's going on or feel that we do not need to know what we have and what are the ramifications of change, we are surely risking our future – one that will continue to surprise us – so long as we survive log enough to find out.

Roger Burlton

Roger Burlton

Roger Burlton is Chairman of the BPTrends Board of Advisors and a Founder and Chief Consultant of BPTrends Associates. He is considered a global innovator in methods for Business Process and is recognized internationally for his thought leadership in Business Process Management. Roger has developed and chaired several high profile conferences on Advanced Business and Information Management and Business Process Management, globally.  He currently chairs the annual BPM Forum at the Building Business Capability Conference in the US and the IRM UK BPM Conference in Europe and his pragmatic BPM global seminar series, started in 1991, is the longest continuous running BPM seminar in the world. Rogers is the author of the best selling book, Business Process Management: Profiting from Process and the Business Process Manifesto. He is widely recognized for his thought leadership in business process strategy, business architecture, process analysis and design and process management, measurement and governance.  Roger graduated with a B.A.Sc. in Industrial Engineering from the University of Toronto and is a certified Professional Engineer in the Province of Ontario.
Share

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share
Share