Do You Really Understand Your Business? Business Architecture To The Rescue!

In Business Architecture, Uncategorized by IRM UKLeave a Comment

Print Friendly, PDF & Email

In my years as a practicing Process and Business Architect I have seen ideas, models and methods evolve dramatically. We have always known that we need to get some grip on the business knowledge that we need to have so we can achieve some critical business intention. For some organizations, it’s all about being able to get through a business transformation or an implementation of some technological change.

Roger Burlton, President, Process Renewal Group, roger.burlton@processrenewal.com
Roger will be teaching the course, ‘Business Architecture Best Practices: Practical Methods to Enable Business Change‘ 3-5 June 2019 and ‘Digital Process Analysis and Design: Optimizing the Customer Experience through Digital Innovation‘ 6-7 June 2019 in London
Roger chairs our Business Process Management Conference Europe 2019, 21-24 October.  The call for speakers is now open here

More and more, for others, the goal is not to just develop architecture components simply to conduct ‘a project’ or solve a single problem. Modern architectures must also have a purpose of longevity, reduction of business risk, sustainable business advantage and ongoing ease of change. In my experience if we only focus on the movement to a new product, service or even a new business model without thinking longer term and retaining our knowledge advantage, then as soon as we finish a particular change we will immediately be re-architecting all over again as part of the next transformation fire drill.

It is clear that we are leaving the so-called industrial age where we had long times in-market and we are entering the knowledge age where constant turmoil and short product and service times in-market will be the norm. Drivers such as digitalization, agile, fickle consumers, new technologies, radically different and cross-entity business models, a social media culture, real time expectations, etc. are driving old ways of working to the scrap heap. Furthermore, there is no evidence to believe this trend will stop or slow down any time soon in this new age.

If we do not have sufficient specific knowledge about our business, then attempting continuous adaptation will be risky with potentially high risks and large impacts of unintended consequences, making the expression ‘the main cause of problems is solutions’ a continuing reality. Some approaches such as agile software development and self management of organizations are helpful but are not sufficient in and of themselves when we are faced with 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

Frameworks

For some time, I have stressed the importance of having a common semantic framework as the practice of Business Architecture has emerged and evolved. As our teams at Process Renewal Group (PRG) have been applying our own methods and techniques, we have more and more relied on the formal structuring of a consistent architectural foundation based on the management of the business knowledge we need in order to discover change impacts and share that knowledge with all parties involved in change. The overall PRG architectural framework has also evolved to be more workable and easier to communicate to practitioners. I will return to this after a look at what has inspired us in the past and what’s available today.

Zachman Framework

John Zachman’s framework categorizes the knowledge needed. It’s structure of columns defining the six primary interrogatives of the What, How, Where, Who, When and Why of an organization will structure what we need to know about the business. Looking at how these interconnect with one another is the magic behind defining business architecture requirements. Taking a look at row 1 (Executive Perspective) and 2 (Business Management Perspective) we see what Business Architecture is trying to address. Looking at the perspectives in rows below (3 through 6), extends the attention to what Enterprise Architects and Developers – especially IT oriented ones – must deal with.

The value that Zachman’s perspective brings as a thinking model is priceless. For example, it shows that Data is not Process, that Business Managers are concerned with different things than Technicians, that a Capability is not a primitive concept but a composite of the other columns and that all primitive models (cells) are connected to others to achieve workable results. Despite what one may think of the framework – and there are many opinions – as an implementable architectural model, this separation and association of concerns and perspectives is essential to all architectural thinking in all domains of society and businesses. It also subtly calls for reuse of objects and thus critically demands the management of business knowledge.

Business Process Manifesto

The Business Process Manifesto (https://www.bptrends.com/resources/bp-manifesto/) describes how work gets done and also its relationship to other aspects of business knowledge in other perspectives needed to support how 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 and that every process has the potential for a more detailed description providing a finer and finer 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 clear 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 is true of all columns.

The Manifesto also presents the reality that a business process – as is true for all knowledge areas – cannot stand alone when it comes to usability. Many of the other columns and composites of them 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 define the integration needed for us to know about if we are to be able to manage holistic 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 of them, it would be helpful to know the impact on the others.

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, investment and design 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 in a way that mitigates unintended consequences. It clearly states that its purpose envisions an ability to modify dynamically the concepts and structures of the business itself and that this ability necessarily requires having the business knowledge to dynamic reconfigure implementation and to continue business operations as business changes are formalized. It was developed in 2017 by John Zachman, Ronald G. Ross and myself in collaboration. It specifically calls out business knowledge as the critical enabler for change and design decisions. It also recognizes the need for a formal knowledge base organized by structured knowledge concepts.

Business Architecture Guild’s BIZBOK

The Business Architecture Guild is a professional membership organization with the intentions 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 how a number of areas are defined and connected. Its areas are structured differently than Zachman but shares the idea that knowledge domains must both stand alone and be connected as needed and embedded into one another. The BIZBOK, for which you will need to be a Guild member to access, can be found at https://www.businessarchitectureguild.org/general/custom.asp?page=about.

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 along 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 for the definition of a standard for a Business Architecture metamodel. The previous sections of this article 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 focussed on common artifacts. At this point, the submitters are collaborating to reconcile differences to be able to put forward one recommendation for how the Business Architecture knowledge should be represented. This will also form the foundation for tool vendors to be able to capture and potentially to interchange model knowledge among tools.

The Process Renewal Group Framework

Our framework has been inspired by the principles of each of the models just described and its knowledge structure reflects our hundreds of initiatives that have focused on their practical implementation. This is the latest framework graphic.

Its four major types of knowledge areas are focused on Defining, Designing, Building and Operating the business. One could argue that this goes beyond the classic definition of Business Architecture, however, we believe that the total set of knowledge required to change anything will ultimately need all of this at some point. It is certainly aspirational. Each of these areas can also be considered a phase of effort to arrive at set of knowledge artifacts to ensure we have a better operational business. It is important to note that the population of the required knowledge artifacts should not be seen as requiring a waterfall plan of attack. That is doing each part perfectly before moving on to the next. In reality, all of the phases are underway to some degree at any point in time. Whatever is defined must be able to accommodate new knowledge and all defined buckets of knowledge must be sustained concurrently.

The model (above) recognizes the iterative nature of the major phases of the development of a business architecture. Practically speaking, the approach and structure is certainly agile in nature – adding new knowledge in a never-ending series of sprints – 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 work needed to deliver rapid change.

Being Practical

Clearly, there are many areas that would be very helpful to know about. Furthermore, the domains and interactions among the areas 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 to start with core set is prudent. Time and maturity will help with the growth.

Short to Mid-Term Domains

In my experience the three key starting areas in the ‘Design the Business’ phase are:

  • Information (Information Concepts)
  • Processes / Value Streams
  • Capabilities

These must connect to business value expected and the strategy from the ‘Define the Business’ phase to answer the questions ‘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 quickly get going to leverage our business architecture for best business value for the right stakeholders including sustaining the knowledge for optimum sustainability.

Change priorities

The two sides of the prior 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 place to star 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 required whereby the most value-added domain component is paired with the consideration of the current performance gap to invest in the High Gain and High Pain choices of Information, processes and capabilities.

Without the business knowledge as to how each depends on one another, poor choices unrelated to strategic drivers will be made risking the ability to realize the best total solution.

Tooling needed

It is clear that knowledge retention as defined in the Business Architecture models is a critical requirement for business performance and 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 and more adaptable work even faster. The problem is that there is typically little commitment today to store the knowledge created in the first place and to sustain it as things change. So long as we are project and deadline based and not product and reusable asset based we will think only short term. We need a knowledge base to keep track of what we’ve got. Smart tools are essential. Full function and sharable toolkits with single definition of all objects and strong impact analysis and what-if capabilities are 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, digital or otherwise. Sophisticated tools with a great repository of business knowledge such as QualiWare, BiZZdesign, Capsifi, Envision, 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 in this space; Visio, PowerPoint, Excel and the like are not choices that can connect the dots and be queried.

Summary

The current reality is that most organizations are knowledge-poor regarding Business Architecture and understanding the impacts of change. What we do have is often 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 and like an aircraft rising too quickly they end up stalling.

Achieving useful Business Architecture capability is a matter of knowledge, maturity and readiness. 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 creating, sustaining and leveraging business knowledge. If we think we do not need to know and believe that we should just get on with the job at hand, we are surely risking our future – one that will continue to surprise us.

Roger T Burlton, P. Eng., CMC, is the President of Process Renewal Group and co-founder of BPTrends Associates, the services arm of the BPM knowledge portal BPTrends.com. Roger will be teaching our Business Architecture Best Practices Worksop coming soon. He is the author of the thought leading book ‘Business Process Management: Profiting from Process’. He is considered the industry leader in the introduction of realistic ways of implementing enterprise BPM programs as well as innovative approaches for organizational and process change. He is the editor of the ‘Business Process Manifesto’ which is now available in fourteen languages and co-author of the Business Agility Manifesto. He is regarded as a realistic practitioner, who delivers pragmatic solutions for his clients. He has helped over one hundred organizations implement BPM and Business Architecture as a corporate strategy in many different industries, countries and cultures. An exceptional speaker, he has chaired over fifty high profile conferences on Advanced Business Architecture and Process Management around the world. To date, he has conducted over seven hundred seminars and has presented to over sixty thousand professionals. His seminars have been translated for diverse audiences around the globe.
Roger can be reached at Roger.Burlton@processrenewal.com. PRG’s web site can be found at www.processrenewal.com.

Copyright Roger Burlton, President, Process Renewal Group

Leave a Comment