Chapter 5: Grand Designs

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

CHAPTER 5

Grand Designs

“The architects won’t let us do that!”, Emily heard someone mutter darkly. Emily wondered, who are these all-powerful architects? Are they the thought police? When she asked her colleagues about what the architects do, they answered vaguely. No one seemed to know what the architects did exactly, but everyone knew they could say ‘no’ to anything that was ‘not part of the architecture’.

Emily wants to know more about these authoritarians. After all, she had worked with an architect on her new house recently and he was far from autocratic. In contrast, he stimulated her thinking, opening her mind to layouts and features that she had not considered previously. Her confidence in the architect grew as they discussed the design concepts for the house, the architect coming back with modifications and new ideas at each session. He gently explained to her why an idea she put forward might not work so well as a livable space, or perhaps needed stronger structures that would add cost to the project. He was willing to modify the architecture to accommodate a new idea, but he also highlighted the cost impacts and other factors that Emily needed to consider as the owner of the house.

When it came time to build the house, her architect worked with the builder to clarify elements of the design, and to resolve issues that the builder thought would be too difficult to build. Emily could not have hoped to work directly with the builder without her architect as the intermediary – she didn’t have enough knowledge of building or even the right language. He seemed to know how to communicate effectively with both her – the client – and the builder. It struck Emily that the architect seemed to have an important role as the intermediary throughout the detailed design and building process.

If buildings need architects, then it made sense to Emily that complex businesses would need them too. Without architects, all the moving parts of a business could be put together badly, and not pull in the same direction, so to speak. Why did her colleagues seem to think that the architects were only there to block their ideas? What was ‘the architecture’ they spoke of, anyway? Had anyone ever seen it? How were Emily and her colleagues supposed to know that the architecture was what they – the clients in the client-architect-builder trio – actually needed? Would her colleagues stand for it if they were left out of the conversation about their new house, and instead the architect and builder built what they alone wanted, as if they were going to live in it? John Nutt, head of the engineers for the Sydney Opera House, pointed to the close relationships that make for a successful building project. The same idea also applies to business projects.

On any building, the greatest collaboration comes from that sympathetic relationship which the architect, the engineer and the client feel for each other.11

Form and function

The fundamental task of an architect is finding the form that will accommodate the purpose of the building. Complex functions are difficult to define at first, but tend to clarify and diverge during design and, over extended time, evolve in conflict with the framework they inhabit.12

The beautiful white shells projecting into Sydney Harbor catch the eye and take the breath away. The alluring vision beckons us to go inside, look around, and perhaps attend a performance. As the Sydney Opera House vividly demonstrates, the form of a building invites engagement with it. As well as form, all buildings must also have function – they are built to fulfil a purpose. The function of the building may not be obvious from its form, but the form must be right for its intended function. Needs change over time and the function of the building must evolve, yet the building’s form is more difficult to change.

Figure 5-1 Sydney Opera House13

The Sydney Opera House dramatically demonstrates this truth. Once the structural form of the famous shells had been constructed, it became hugely problematic to change the function of the interior spaces – but that’s exactly what happened. The building’s client decided to change the function of the main hall from opera to concert performances after detailed design and construction had been underway for some years. The architect was faced with the extraordinarily difficult task of designing new interiors within the now-complete and unalterable structural form, with only limited success. These evolving functional requirements added a huge extra cost and delay to the project before it was even open. A completely new architecture was required for the interior spaces. Acoustic and other problems have plagued the building as a result. Further evolutions in function have emerged over the years since the Sydney Opera House was opened in 1973, making consequent – albeit less drastic – modifications to the building’s form necessary.

The ‘form’ of a website also invites a browsing customer to engage with it; you feel drawn to a website that is engaging. On the other hand, you may feel turned away by a website that looks uninviting or makes it difficult to find what you want. Getting the ‘form’ of the website just right is the first job of user experience designers. But the experience that users feel when they interact with the website is merely a facade of the actual business, like the foyer of a building. The foyer of the Opera House fulfils a necessary function, but a function that is subsidiary to the ‘main event’ of the performance halls. The functions that go on inside the ‘form’ of a business are dominated by the operations in the business’s back office, away from the eyes of the customer, who don’t know or care about them – unless it results in a terrible service, of course.

A complex business supports many intersecting functions, just like a complex building. The performances that occur in the Sydney Opera House rely on many non-public spaces and systems: the dressing rooms, rehearsal spaces, stage apparatus, power supply, air conditioning, communications systems, and so on. The concert patrons care nothing of these matters – that is, unless something goes wrong that affects the quality of the performance. Maybe the lights go out midway through a performance. Maybe the performer in their dressing room was not communicated with and misses their cue.

The ‘back office’ systems that enable a theatre to host a performance without such hiccups, or worse disasters, will be familiar to any experienced performer, stage manager, producer, musical director, and lighting director, even when they have never used that theatre before. The systems are based on well-established patterns used in theatres throughout the world. These patterns enable a crew to ‘bump-in’ to an unfamiliar venue and put on a flawless show, albeit perhaps masking any creaks and groans from the eyes of the audience.

Likewise, the back stage of a business also relies on patterns that are familiar across many different businesses. For example, the accounting, ordering, billing, and payments processes and systems will be familiar to a new member of staff in the finance team. The back-office functions, and perhaps even the front office, will “evolve in conflict with the framework they inhabit”, just as the functions of the Sydney Opera House evolved considerably from the initial brief to the architect.

Fortunately, it is easier to evolve a business’s front office to meet these evolving needs when it is built in furnishings and software, rather than pre-stressed concrete. A website’s ‘form’ can be readily changed or completely rebuilt to accommodate new functions. However, the back office has a structural form that is not so easy to change quickly. The ‘structural form’ of the back office is too-easily hard-wired into complex information systems by the system development practices commonly in use. For this reason, the funding required to modernize complex processing systems is often eye-wateringly large. So, when changes to the business’s ‘function’ are required – say, a new business line, a new compliance requirement, or a streamlined business process – a significant and costly change to the ‘form’ of the information systems becomes necessary. Fortunately, as this book will show, it is possible to minimize these costs and to increase the speed of making a change.

Why does business need an architecture?

In the previous chapters, we have introduced the idea of stakeholders transacting with each other, we have demonstrated why data is important, and we have shown how transactions fit with the contemporary Service Design approach with its emphasis on the customer perspective. Now let’s have a look at a more internal perspective, the architecture of a business.

Most people have an idea of what building architects do and why, but business architects? What on earth do they do? Nowadays there is a confusing array of architects involved in business information systems, with job titles that poorly describe what they do. We have data architects, information architects, IT architects, solution architects, security architects, process architects, enterprise architects, and – most importantly for this discussion – business architects. Their job is somewhat difficult to comprehend – indeed, many businesses think they don’t need a business architect. Sadly, many architects think their job is nothing more than setting standards and rules which they then enforce rather stridently. These are the kinds of architects that Emily’s colleagues have encountered in the past.

This chapter offers an introduction to the role of the business architect and how they can help you.

Once she understands what they do, Emily realizes that the business architect is her new best friend and their relationship doesn’t have to be antagonistic. Emily learns that good business architects bridge the gap that often resides between the strategy that the organization’s leaders want to pursue, and the everyday systems and processes that are the engine room of the business. When this gap is neither recognized nor filled, change initiatives can go badly awry and the resulting systems and processes are misaligned with the strategic intent. Strategy is often poorly communicated, and staff are disengaged with it.

Business architects expose the chaos that lurks in most businesses. The business units within an organization are often characterized as silos, isolated from other business units. A more apt term than silos is perhaps ‘tribal fiefdoms’. Fiefdoms do things their own way, according to the wishes of the leader or perhaps according to the ‘group think’ that permeates it. Strongly siloed environments result in a sprawling shanty town of systems and processes that are unplanned and uncoordinated. This isolationist thinking prevents business units from working effectively with other units to deliver end-to-end services to their customers. It is a primary cause of inconsistent customer experience and breakdowns in service delivery. In summary, it is chaotic.

Business architects, alongside customer experience experts and service designers, can help to show how the business unit fiefdoms can work together far more effectively, by bringing transparency to the chaos. Business architects identify the building blocks of the business, and they discover how these building blocks relate to each other and to other elements of the business. The building blocks – referred to by business architects as ‘capabilities’ – describe what the business does, but not how it does them. When an organization has a capability, the capability enables the delivery of products and services to its customers.

A simple example of a capability is a hammer and the skill to use it properly. A hammering capability is one of the building blocks of a home handyman’s ability to fix things around the house. Without work to do, however, a capability lies idle – it doesn’t do anything unless it is supplied with work. When you need a picture hung on the wall, the handyman’s hammering capability is utilized and delivers value to the stakeholders; your partner, children, and visitors will appreciate the visual appeal and aesthetics of a well-placed picture.

A key part of a business architect’s work is to analyze capabilities and to describe them accurately and unambiguously. The architect will ensure that the capabilities they define don’t overlap with each other and that they each have a business unit that is responsible for its content and development.

A capability is related to many other elements of the business:

a capability is linked to the business units that possess it;
a capability is linked to the information that it captures and uses;
a capability is linked to the business processes where it is employed;
a capability is linked to the business systems that enable it; and
a capability is linked to the value streams that depend on it.

As we saw in Chapter 4, a value stream is a simple map that shows how the business delivers value to its customers. There are usually four or five services to a value stream, each one delivering something of value. A customer may engage with each service separately and not necessarily in a linear order. A business builds and evolves the capabilities it needs to enable their value stream. Capabilities also link, through the value stream, to the customer touchpoints in the customer journey map. This linking shows us how a back-office capability contributes to the delivery of customer value and how it influences the customer’s experience.

To illustrate one way in which capabilities are related to other elements, Figure 5-2 shows the value stream and the matching capabilities of an organization that manages events. For example, the service called “Plan and market the event” relies on two capabilities – Event Planning and Event Marketing. This simple partitioning enables us to examine each capability separately to determine whether there is anything that could be improved, so that the business delivers better value to customers at that part of the value stream.

Once identified and described, the architect will develop rough relative measures of how ‘healthy’ the capability is – does it need improvement? As further information and relationships are added to this knowledge base, which is founded on a solid understanding of the capabilities, you have a business architecture that can be used in planning and deploying initiatives to make improvements.

A well-constructed, communicated, and implemented business architecture enables greater reuse of capabilities across the business. The architecture reduces duplication of capabilities by pointing out the areas where duplication currently exists – e.g. two business lines that both operate high-volume printing facilities, using different technologies, vendors, procedures, and templates. Although the two business lines consider these facilities to be different in many ways, the business architect recognizes that they are, in fact, different implementations of the same capability. The architecture identifies an opportunity to consolidate the two printing capabilities into one shared capability, thereby reducing the overall cost of operating and maintaining the facilities.

Removing the doubling up of large printing facilities is an obvious example of how sharing a capability can trim excessive costs, but duplication of capabilities exists at a micro level as well. For example, many business systems contain specific screens for decision-makers to approve various actions – approving a loan to a customer, for example. As we shall see in later chapters, it is possible to design and build a shared capability for making decisions like this, called something like ‘Approvals’ or ‘Decision Management’. A shared Approvals capability would enable all decisions to be stored centrally, using a common data structure and a closed, identical set of decision types (e.g. Approved, Declined, Returned). This consolidation and uniformity would enable improved management information and faster implementation of new processes that reuse the shared Approvals capability.

Business architects understand how the business works, and how well

Business architecture and service design both deliver insights on how the business delivers value to stakeholders, albeit from differing perspectives. Business architecture is a logical, internal view, whilst Service Design provides a customer experience perspective that has a more emotional basis. Both perspectives are valuable and they complement each other.

Chapter 4 explained how a business offers customer-facing services that are placed above the line of visibility in a customer journey or service blueprint. Business architecture resides below the line of visibility. Below the line, unseen by customers, lies the internal view of the value stream representing the business’s intent concerning the delivery of value to stakeholders. The business realizes this strategic intent by leveraging its capabilities, perhaps enhancing the capabilities and building new capabilities over time. The associations between customer experience, services, and the business architecture are illustrated in Figure 5-3, which shows how these concepts interrelate for an event management firm.

The customer journey and the internal business story interlock. There is a close relationship between the customer experience design (as represented by the future service blueprint) and the business issues that may need to be resolved during the project to bring the blueprint to reality. Likewise, the potential issues at points where customers interact and transact with the business bring fresh insight to business units that currently impact these touchpoints negatively. This alignment between the customer experience design and the business architecture enables rapid translation of customer touchpoints into the business capabilities that deliver them.

Business architects develop an understanding of how the many elements of the business, from its building blocks upward, work together and consequently how the elements affect each other. Your new business architect friend is well-connected with the intent of the business leaders, and with the IT projects that deliver improvements to business systems. Your friend is an important conduit enabling the flow of consistent strategic information between business leaders, business units, and IT project teams.

Operational performance and agility are other ways in which business architecture helps a business. A key aspect of the business architect’s job is to pinpoint where changes should be made that will lift performance through, for example, investment in a new system or reengineering of a business process. A good measure of business performance is what author Chris Potts terms ‘structural performance ratios’.14

Structural performance should be more significant to senior managers than the simple and commonly-used measures of inputs and outputs, because structural performance indicates not just what the business is producing (sales per quarter, for instance) but how well it is doing that. Typically, structural performance measures are ratios of output per unit of input – e.g. a ratio such as ‘sales per unit of operating cost’.

The data required to calculate these ratios can be derived from numbers found in reports such as the firm’s balance sheet; therefore, complex business intelligence systems are not required to produce them. The data used is not micro-level data, so the structural performance ratios do not reflect the minor peaks and bumps that occur in normal operational processing. In contrast, structural performance ratios indicate long-term trends – i.e. they point to possible structural problems. The trend in a structural performance ratio over time gives a strong indication to managers whether the business is getting better at what it does, or worse. A worsening trend in the ratio is a clear signal that an adjustment needs to be made to the organization’s architecture. This is where the business architect should be called in.

Adjustments, large or small, are made to a business’s operational architecture to maintain its peak fitness. Business architects point to the places that need such adjustment – there may be many such adjustments that are evidently needed. The work of a business architect helps to prioritize the proposed initiatives by highlighting the changes that could reap the most benefit or that are necessary before a dependent adjustment can be made. There are many complexities and inter-dependencies that must be understood before any part of the operating model should be changed. This factor acts as a restraint on business agility. Business architecture, if done well, will lend agility to the business by revealing the connections between elements of the business. This enables a change to business operations to be made quickly and confidently, because the implications of the change can be readily identified and understood.

Note: in many organizations, the business architecture team sits within the IT function – this can cause the team to be seen by business people as part of an IT project team and therefore only interested in IT matters. Effective business architects keep themselves at arm’s length from IT. Business architects placed within IT will always be drawn towards seeing things through an IT lens. But many of an organization’s building blocks are not IT-enabled, so an IT-centric view of the business is a distorted one. A good business architect will insist on being placed in a business unit separate from IT.

How does architecture help Emily?

Armed with these tools, the business architect helps Emily to fully understand the business context of the unique transactional service that she is working on. Emily talks to the architect about how a model of the business capabilities can help her – how is it relevant to what she needs to do? The capability model seems very high-level, which might limit its usefulness to her business unit. How does being friends with the business architect in her organization help Emily with specifying the detail of an individual transaction and implementing the transaction well? We explained earlier in this chapter about reusing capabilities and minimizing redundancy – Emily wonders if this factor is the key to unlocking the value of a business capability model for a specific transaction?

The business architect should possess a solid knowledge and understanding of the many elements of the business that a transaction relies on to operate well. These business elements enable, or are affected by, a transaction, as illustrated in Figure 5-5. A wide range of elements enables transactions. These include not only the business capabilities but also the functional structure of the organization, the business systems and the data that they capture and supply to the transaction, and the infrastructure on which the systems and communications run. While all these elements enable a transaction, the way in which a transaction is designed and implemented directly affects, in turn, the quality of the customer’s experience.

The business elements that surround transactions are described by the architect in various architectural views of the business. Business architects create views to break down the complexity of the real business, in much the same way as building architects create drawings and specifications of viewpoints of a complex building. A building architect creates separate perspectives that look at the building from above (plan view) and the sides (elevation views), as well as drawings that represent only the structural components, another set of drawings for the plumbing components, another for the electrical wiring, and so on. The architecture of a building, even a very simple one, cannot be communicated effectively with only one of these representations. But it is important that the plumbing of the building works as a complete system, so that water entering and leaving the building is adequate as well as being controlled effectively. A plumbing blueprint is specific – it will show only the plumbing components located within the building’s structure, but it will not include any detail of the structural elements, nor of the other systems in the building. So it is with businesses. Business architects, and their counterparts in the IT team, develop many views of the organization from different perspectives. Examples include the following, among others:

a map showing the broader context of the business
an information model
an organization map
a capability map, or
an inventory of business applications.

Already in this chapter we have seen that the business capabilities – the centerpiece of a business architect’s work – enable the processing of transactions. So, a business capability model is a vital view of the business. Another important view is the business strategy (and, in government organizations, the intent of a policy or program), which provides overall guidance to the organization’s work. A map of the business’s value streams delivers a viewpoint of the organization’s strategy from the lens of delivering value to its customers. A value stream shows how value is delivered through several services, not necessarily in a linear sequence. (Value streams were discussed in more detail in Chapter 4.)

An organization map is useful because it shows visually how the business is structured. It shows much more than the management hierarchy, as it can also show how functions are distributed across the business units and where they are located. The business units that have responsibility for certain functions perform the work needed to process transactions – Emily is a member of such a unit. Models of business processes and workflows represent how work tasks are sequenced and distributed to work teams.

Since transactions create or update master data, another helpful model shows the information created or used by the transaction. Your business architect will most likely work with abstract views of data called data subjects – these are the nouns, such as Customer and Product, that label the objects your business keeps data about. We discussed data in Chapter 2. A data architect will develop knowledge, at a more detailed level, of the specific attributes of these data subjects and design the technical storage of the data.

Using their knowledge of all these elements, Emily and the business architect work together to gain an appreciation of the business context of her transaction. Several interesting questions emerge that Emily wants to find the answers to.

What other transactions are the neighbors of this transaction in the value stream?
What capabilities enable this transaction?
What other transactions and customer interactions use the same capabilities, and can we share the capabilities effectively?
When a business function has a role to play in this transaction, what other transactions is the function involved in?
Might there be any issues of contention between business functions over the design of this transaction, or the way the operation of it is managed?
How will the workload of a business function be affected (reduced, increased, made easier, made harder) by the change we are thinking about making to this transaction?

This information sounds very helpful to Emily, but she worries that it might dampen the freshness of the customer experience perspective from Service Design, which had also helped her a lot. Now she is beginning to feel stuck between the business architect and the service designer – they seem to have opposing points of view. When specifying the details of a transaction, Emily certainly should refer to the service designer to ensure that the transaction design is in keeping with the service blueprint. This collaboration with the service designer helps her to retain a customer perspective when she gets down to the detailed specification of the data fields needed, the interactions that might be invoked during a transaction, how the customer might feel about those interactions, and so on. Retaining a clear view of the customer journey helps Emily to specify a better transaction, at least from the customer’s point of view.

Placing emphasis solely on the customer’s perspective, though, can result in a transaction design that causes a less-than-brilliant internal process journey for Emily’s operations team. The IT project team, that has the job of building new system components to support a transaction, may say that the service blueprint is enough, let’s get on with prototyping the user interface screens. Emily protests this approach. A service blueprint on its own does not give Emily the assurance that the existing and proposed business components are all aligned so that they properly implement the new service blueprint. The business architect restores balance by helping Emily with the internal perspective of the transaction.

A service designer (sometimes called a customer experience (CX) designer) and a business architect have different perspectives, as shown in Figure 5-6. The figure shows three major areas that must work together to deliver business services and value to customers – Presentation, Action, and Concept. At the center, Action is where the activities of the business and its stakeholders occur. The Action area contains the capabilities possessed by the business, such as the workforce, business systems, data assets, standard operating procedures, and so on. The Presentation area makes the Action layer visible to stakeholders and enables stakeholders to interact and transact with the business. Underpinning the Action layer, the Concept area abstracts the key concepts of the business – the operating model, the data subjects, the value streams, the strategic intent.

A great solution needs each of the three layers to be individually great – an easy-to-use and engaging Presentation layer, and an effective and efficient Action layer, underpinned by a sound and durable architecture in the Concept layer. Many customer experience designers work only with the presentation aspect of a service, while many architects spend all their time working only with the abstract concepts. While the attractiveness and beauty that results from good presentation design are important, so too is the integrity that results from getting the fundamental concepts, and their interplay, just right. The deeper a designer can penetrate beneath the Presentation into the Action and Concept layers, the more integrated the solution. Likewise, great architects penetrate upwards to give attention to the Action and Presentation areas that lesser architects consider to be merely superficial.

Competent service and customer experience designers and business architects complement each other very effectively. Mike Clark, a leading practitioner in the service design field, summed this up well in a recent webinar: “The combination of customer experience and business architecture will enable stakeholders to design and evolve their business around the experiences of people.”15

Three key points from this chapter

Business architects have a unique set of skills and knowledge that help to build transactional services that align with the organization’s objectives and are robust and resilient.
Transactions have dependencies on many elements of the business and a thorough understanding of all these is vital.
Capability maps are a key foundational tool that can be used in many different ways to gain valuable perspective about the entire business, as well as about individual services.

Table of Contents for Chapter 5: Grand Designs

Create new playlist

Sign In

Sign Up

Table of Contents for
Chapter 5: Grand Designs