I know very few people who specialize in one area of IT/business architecture yet have practical knowledge of how all of the areas fit together. Roger Burlton is one of those people. Roger has expertise in business process management, but has deep and vast knowledge of all facets of an organization’s business architecture. It is one of the reasons why I am delighted that he wrote his latest book on business architecture.
In addition to covering all facets of business architecture, Roger explains approaches and frameworks without bias. He objectively describes frameworks such as Zachman, TOGAF, BIZBOK, and the Burlton Hexagon. Many examples made the concepts more concrete for me, and his conversational writing felt we were chatting by the coffee machine.
He has a wonderful introduction to his book:
My perspective will be somewhat wider than many conducting this type of work. I include more than a set of models for information, processes (value streams), and capabilities in a business architecture discipline. I also include strategy issues, including ecosystem assessment and external stakeholder analysis. For me, a business architecture must also deal with performance and the performance structure of the enterprise or value chains in scope. A business architecture is so much more than a set of capabilities that IT professionals must build. As Figure I-1 shows, IT must enable and deliver new abilities and ways of working to keep the enterprise relevant and sustain its success operationally in all aspects of change and not just technology.
Click to view larger.
There are clearly many things we need to understand to be useful business architects. Some time ago, I was sitting outside on a beautiful day at a conference venue for an event that I was chairing overlooking Darling Harbour in Sydney, Australia. In discussion with other conference speakers—and after several beers—we discussed what makes a good business architecture. The consensus was that ‘connecting the dots’ was critical due to needing to understand the impact of a potential change in any item on everything else in play. I commented that to ‘connect the dots,’ we would have to ‘collect the dots’ first or we just have a blank page, and no useful drawing could be established or shared. It would be like developing the solution without knowing the need. That launched a search for similar words—remember it was a group of nerds after several drinks—but we could only come up with one more, and that was ‘correct the dots.’
We were very proud of ourselves, so we ordered another round of drinks. That was the source of the credo I have used ever since and how the book got its name. Each of these practices will show up as I tackle the various domains of business architecture in the following chapters. Sometimes we will collect all then connect. Sometimes we can work in a defined scope and connect as we go in an agile and iterative learning cycle.
We will always try to correct once we have enough knowledge to proceed. All three phases will be discussed along the way in a logical order, although that order is fluid based on the need at hand. I will talk about the reason for business architecture first. A business architecture will be inevitable for organizations to survive as pressures to respond to real-world conditions accelerate.
The book will follow the structure described below.
In the first section, I will deal with the foundational issues upon which business architecture depends. Chapter 1 will get us started by looking at the pressures facing our businesses today and those that we may anticipate seeing in the future. These are mostly from the external world—our ecosystem. These certainties and uncertainties force us to be constantly vigilant and ready to change and drive the need for business architecture. Chapter 2 will examine the heritage of business architecture methods and practices since most aspects have been around in some form or fashion for some time. It is useful to know their perspective – some would say their bias. It will also introduce our business architecture landscape that assembles the various points of view. This framework structure is the focus of the remainder of the book. Chapter 3 will help you establish the scope of your architecture and identify the lines of business that you will take on. In doing so, it will introduce the concept of value chains within which our value streams will be found.
The second section will focus on gathering the critical knowledge needed—Collecting the Dots. Chapter 4 will examine the ecosystem of the organization and value chains in scope. Chapter 5 will enable you to derive the guidance and decision criteria needed from the business strategy to make later investment and design choices. Through establishing a business concept model, Chapter 6 will help you develop the semantic baseline to assure a common language going forward. Chapter 7 will introduce the techniques required to establish your process architecture, including connecting your value chains with value streams, stages, and business processes. Chapter 8 will help you to establish your business capability map. These chapters gather and validate the building blocks of a sound architectural framework.
The third section will show you how to identify the interconnections we have collected—Connecting the Dots. Chapter 9 will include establishing a robust Business Performance Measurement structure. In Chapter 10, we will connect and align the architectural domains collected earlier.
In the last section, we start the journey of Correcting the Dots by prioritizing change in Chapter 11 and building the change portfolio in Chapter 12. In the last chapter, I will present examples of the need for tackling Business Architecture from a pragmatic point of view that emphasizes needed variability in how the dots get connected. We have to be relevant and solve real problems and in Chapter 13, I present the case and thinking needed.
