Business Architecture Grid

In some of my posts, I have used the terms vertical and horizontal in relation to Business Architecture. The purpose of this post is to analyse what these terms actually mean.

Firstly, the word vertical is often associated with value chain thinking. Typically, there is a process that spans from the raw materials to the finished product or service, and this process may either be divided between different actors or controlled by a single actor. Where a single organization controls the end-to-end process, this is known as vertical integration.

Large organizations typically have several versions of these processes, or even several entirely different processes. Bunding these into a single organization only makes economic sense if they can share resources and other stuff. For example, if procurement is done jointly, this may give the organization more buying power.

So there are typically a number of cross-cutting concerns, which may be referred to as horizontal. TOGAF 9 (released in 2009) identified "rich domain knowledge of both horizontal, cross-cutting concerns, such as human resources (HR), finance, and procurement alongside vertical, industry-specific concerns" as fundamental to Business-Led SOA.

So one version of horizontal integration involves establishing shared capabilities or services, which may support multiple value chains. Even when these value chains are distributed across different companies across different market sectors, one actor may seek to dominate the provision of these shared services, whether by merger and acquisition, technological superiority, or sheer market power.

In a 2005 discussion on Efficiency and Robustness, Stu Berman commented

The US economy is remarkably resilient to a wide variety of shocks (9/11 is a good example, as is Katrina) due to our horizontal integration rather than vertical. It is easy to look at history and see where colossal economic problems occurred - Soviet central planning, Nixonian gas price controls. via Chandler Howell

I have always argued that Business Architecture requires multiple Viewpoints. One reason for this is that the Activity or Value Stream viewpoint concentrates on the vertical dimension, while the Capability or Service viewpoint concentrates on the horizontal dimension. (Further viewpoints are required, because business architecture is not simply a two-dimensional problem.)

Note that the terms vertical and horizontal also appear in discussions of technology architecture, where they mean something rather different.

 

---

Further discussion

Efficiency and Robustness: Central Planning (September 2005)

Business-Led SOA (February 2009)

Towards an Open Architecture for the Public Sector (May 2014)

 

See also

Philip Boxer, The Double Challenge (March 2006)

Richard Veryard, Six Viewpoints of Business Architecture (LeanPub, 2012)

Executive Moves

Before the start of the football season, football journalists have little to write about except transfer speculation - wondering which player might be about to transfer from one overpaid job to another overpaid job. This period is known as the Transfer Window.

The simplest assumption is that a player's talent is completely transferable from one club to another. His individual performance at his new club will be similar to his individual performance at his old club, and this is why he commands a particular market valuation.

Of course it is never as simple as this. An astute manager may spot a player who is performing poorly for his current club, and may be able to acquire such a player cheaply, at a price that doesn't reflect his full potential. A well-known example is the transfer of Thierry Henry from Juventus (where he had a disappointing season playing on the wing) to Arsenal (where he made his name as a world-class footballer).

Conversely, there have been many players who have been transferred at inflated prices, and who have then performed disappointingly for their new club. Any football fan will be able to name examples. The possible reasons for such failures range from personality clashes and team culture, to differences in team strategy and style. A player that is brilliant in one formation may struggle in an unfamiliar formation. (See Wikipedia: Soccer formation.)

Similar considerations may apply when a senior manager moves from one company to another. An executive commands a high salary because of a widespread belief that her skills and experience are easily transferable within the same sector, or even across sectors. Thus if a company has challenges in (say) supply chain, it seems to make sense to poach some supply chain expertise from elsewhere.

This is turn relies on an assumption that supply chain is basically the same everywhere. In business architecture, such assumptions result in enterprise models that abstract away from what makes each company unique, and concentrate on showing what all companies in a given sector have in common. So naturally there will be a box called Supply Chain. (Or Supply Chain Management, or Manage Supply Chain, or whatever your naming standards dictate.)

When an executive move doesn't work out, this often leads to suggestions of personality clashes or company politics. Technocrats love these explanations, because they regard such matters as beyond their understanding or control. But personality clashes and company politics are often symptoms of some deeper (structural) differences. Perhaps the challenges of supply chain innovation (and the creative tension between supply chain and other capabilities) are not the same in all companies; in which case, we should be wary of relying too heavily on enterprise models that make supply chain appear the same everywhere. Obviously business architects are interested in the things that companies have in common, but business architects must also be able to articulate (and help reinforce) those things that make a particular company unique.

In my presentation to the IASA conference in April 2013, I discussed the evident differences between hi-tech companies (Amazon, Apple, Facebook, Google, Microsoft, Oracle), and challenged business architects to explain these differences in structural terms. I have my own ideas about how this can be done, and I am interested to hear other ideas.

Architecting multi sided business 2 from Richard Veryard

---

@wimrampen writes that this post fits well with @jhagel's Strategy Made Simple. "Nothing simple about strategy ;) but @jhagel does great job showing what's really important", adds @wimrampen.

Not your grandpa's functional decomposition

Is there a difference between function and capability? You can find endless debate about this on the Internet (yawn). One of the reasons business architects often prefer the word capability is that the word function can become extremely overloaded - sometimes equivalent to organizational unit, sometimes equivalent to long-running process, sometimes equivalent to purpose. Whereas the word capability seems to focus our attention more clearly on the WHAT rather than the HOW or WHO or WHEN or WHERE or WHY.

But even when people insist that a capability is not the same as a function, they still seem to use the same approach for identifying and modelling capabilities as was once popular for functions. So they draw capability models as simple hierarchies, either as trees or as boxes within boxes. There are many valid uses for these models, including heat-mapping.

One such approach to capability modelling was popularized by Ric Merrifield and others at Microsoft in the mid 2000s. The methodology was originally called Motion, then Motion Lite, and is now known as Microsoft Services Business Architecture. It includes a Business Dependency Network diagram, but this is used to show the dependencies between the business architecture and IT, rather than the dependencies within the business. In fact, it looks remarkably similar to IBM's Business Component Model.

Despite the limitations of a hierarchical methodology, there are some useful guidelines on separating WHAT from HOW, and on the segue from capability to service, as well as a wealth of examples.

In the early 2000s, I started working on an alternative approach to capability modelling in collaboration with the CBDi Forum. This approach, which is loosely aligned with Stafford Beer's Viable Systems Model, concentrates on understanding the dependencies between core capabilities, and the role of key management capabilities such as coordination and intelligence. One of the key drivers for this work was the belief that a network view of capabilities provided a good starting point for developing a shared service architecture (both business and IT). This topic has gone off the radar lately, but I think it remains important. 

---

Denise Cook, Business-Capability Mapping: Staying Ahead of the Joneses (MSDN March 2007)

Ulrich Homann, Jon Tobey, From Capabilities to Services: Moving from a Business Architecture to an IT Implementation (MSDN April 2006)

Ric Merrifield, Rethink (FT Prentice Hall 2009) (pdf intro)

Ric Merrifield and Jon Tobey, Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion (MSDN May 2006)

Ric Merrifield, Jack Calhoun and Dennis Stevens, The Next Revolution in Productivity (Harvard Business Review, June 2008) (pdf)

Martin Sykes and Brad Clayton, Surviving Turbulent Times: Prioritizing IT Initiatives Using Business Architecture (Microsoft Architecture Journal, June 2009)

Richard Veryard, Business Modelling for SOA - Capabilities and Events (CBDI Journal January 2006), Capability Dependency (CBDI Journal May 2007)

Richard Veryard, Six Viewpoints of Business Architecture (LeanPub 2012)

Related posts: IBM's Component Business Model (March 2005), Merging Capability Modelling with Process Modelling (April 2008), Business Capability Modelling (March 2009), Organizing Business Capabilities (February 2012)


Updated 31 July 2014

Business Architecture and Related Domains

The following post is an extract from my draft eBook Business Architecture Viewpoints, available from @Leanpub

---

There are some things I don't regard as part of the Business Architecture but as part of some other domain.

One reason for these exclusions is that am trying to avoid scope-creep - putting everything into the Business Architecture that has (or should have) a good link to business. I regard it as the task of Enterprise Architecture to coordinate between Business Architecture, Solution Architecture, Technology Architecture and whatever other domains the enterprise might need.

Which is why I am reluctant to add a Technology View to the Business Architecture. I am also unwilling to extend the Motivation View to include business case, because I regard the business case (despite its name) as belonging to the Solution Architecture. Documents are also part of the Solution Architecture.

Solution Architecture

Key Elements: Business Case (for Solution), Solution, System (including both Sociotechnical System and Software Application), Transformation, Use Case, Workflow.

Note that the Solution domain covers the whole sociotechnical solution space, not just the software application.

Note also that some frameworks (notably RM-ODP) define an enterprise viewpoint covering the purpose, scope and policies of a system. Because of the specific reference to a system, I do not regard the RM-ODP notion of enterprise viewpoint as equivalent to Business Architecture. It could be understood either as a business-oriented viewpoint within the Solution Architecture or as a mapping between the Business Architecture and the Solution Architecture.

Technology Architecture

Key Elements: Business Case (for Infrastructure or Product or Technology), Technical Commodity/Service, Technical Device/Mechanism

Within the Technology Architecture, there is a clear distinction between the abstract technology (for example "middleware", "SOA") and a specific technical product or platform (for example "IBM Websphere"). There is also a distinction between the technology-as-built and the technology-in-use.

Development Architecture

Key Elements: Project, Requirement, Development Lifecycle

Tom Mochal defines development architecture in a broad sense to include three major areas:

* The development life cycle and processes used to build business applications
   
* The application models that show the appropriate technical design that will best fit the business requirements

* The inventory and categorization of the business applications that exist within the organization today.

Physical Architecture / Environment

Key Elements: Building, Location, Equipment

Many IT people use such terms as Physical Architecture or Environment to refer to computer hardware. But I'm using the term to refer to all aspects of the physical environment, such as office buildings and physical equipment.

Where does Location belong? Traditionally this is regarded as part of the Business Architecture, but I believe it belongs somewhere else, along with buildings and working space and the kind of architecture associated with Le Corbusier and Frank Lloyd Wright. Ideally I'd want to call this the Physical Architecture, which would include a Geographical View or what Stewart Brand calls Site. I'd also include something I call Consilience.

Of course, location doesn't disappear in a global organization, but it doesn't dominate business processes in the way it once did, and is often merely a cost factor or speed factor. It is not geographical distance that matters any more, but abstract notions of distance, including commercial, semantic and cultural distance.

Managing Business Transformation

Just putting together the material for my new workshop next week.

This is the third day of my Business Architecture series. The first two days cover the six business architecture viewpoints. The idea is that people can tale these separately or together.

Day One - Modelling Business Operations 
Exploring process quality issues using the Activity Viewpoint, Knowledge (Information) Viewpoint and Motivation (Purpose) Viewpoint.

Day Two – Modelling Business Organization 
Exploring business relationships and strategy, using the Capability Viewpoint, Responsibility (Organizational) Viewpoint and Cybernetic Viewpoint.

Day Three – Managing Business Transformation 
Process guidelines and roadmap for business architects to analyse and manage structural change in large complex organizations.

Functional Organization at Microsoft

@iamjaygreene and @jimkerstetter of @CNETNews are not surprised by the departure of unpopular Windows boss Steven Sinofsky from Microsoft.

• Jay Greene, Steven Sinofsky: Microsoft's controversial Mr. Windows 8 (CNET 21 October 2012)
• Jim Kerstetter, A tale of two execs: Microsoft's Sinofsky and Apple's Forstall (CNET 3 November 2012)
• Jay Greene, Shocked by exit of Microsoft's Sinofsky? You shouldn't be (CNET 12 November 2012)

Some pundits (e.g. ZDnet's Larry Dignan) had predicted that Sinofsfy would survive if Windows 8 was a commercial success. By letting him go immediately after Windows 8 went live rather than waiting, Ballmer has clearly signalled that it is not about Windows 8 success but about something else.

In pieces written in the weeks before Sinofsky's departure, Greene and Kerstetter mention the following issues.

• Sinofsky successfully battled with Ray Ozzie for control of Windows Live Mesh. Ray Ozzie left Microsoft immediately after Ballmer folded Windows Live Mesh into Sinofsky's organization.

• According to unnamed critics within Microsoft, Sinofsky created a rigid product development process that puts more control in his hands and diminishes Microsoft's ability to innovate.

• In a similar fashion to Scott Forstall at Apple (who also lost his job recently), Sinofsky zealously promoted his group's work at the expense of the rest of the company.

• Manu Cornet's cartoon of Microsoft's organization chart is thought to be a reference to Sinofsky.

 

But this story isn't just about personality clashes and organizational politics. Sinofsky has championed an approach to organization structure, which he calls Functional Organization, and this is described in a book called "One Strategy: Organization, Planning, and Decision Making," (2009) co-written with Harvard Business School professor Marco Iansiti.

The Functional Organization builds management reporting lines around job functions -- such as product management, development, software testing. This may be contrasted with a Product Organization where multi-disciplinary teams work on specific feature sets together.

Sinofsky and Iansiti argue that functional organizations create clearer road maps for workers to march toward a final goal. However, critics within Microsoft disagree. Apparently referring to Sinofsky's Functional Organization, Charlie Kindel, another ex-Microsoft executive is quoted as saying that "it represents a siloed perspective, it represents an us versus them perspective".  Another former senior executive (unnamed) has referred to the approach as "Soviet central-planning", where tight control from the top squeezes out innovative thinking from below.

Announcing Sinofsky's departure, and the appointment of Julie Larson-Green as his successor, Steve Ballmer wrote "The products and services we have delivered to the market in the past few months mark the launch of a new era at Microsoft. To continue this success it is imperative that we continue to drive alignment across all Microsoft teams, and have more integrated and rapid development cycles for our offerings. ...  Her unique product and innovation perspective and proven ability to effectively collaborate and drive a cross company agenda will serve us well as she takes on this new leadership role".

(BBC News 13 November 2012)


So is this the end of the Functional Organization in Microsoft? Martin Fowler talks about the oscillation between FunctionalStaffOrganization and TechnicalStaffOrganization, essentially the same dynamics (he reckons) as drive the boom-bust cycle of EnterpriseArchitecture. (PreferFunctionalStaffOrganization). So perhaps now the cross-company silo-busting agenda will have the ascendency for a little while.

Except that the new organization also seems to attract the label "functional".

In a 2,700-word internal memo rich in management-speak drivel , Ballmer announced a "far-reaching realignment of the company that will enable us to innovate with greater speed, efficiency and capability in a fast-changing world". The various internal warring silos known as "product groups" will be disbanded and the entire company (97,000 employees) is to be rejigged on "functional" lines (engineering, marketing, advanced strategy and research), with the aim of "focusing the whole company on a single strategy".

John Naughton, How Microsoft spent a decade asleep on the job (Guardian July 2013) 

The Purpose of Business Architecture

What is business architecture good for? Here are some suggestions.


Designing Organization Structure. Restructuring the organization and reassigning responsibilities are commonly seen as ways of dealing with poor performance, poor governance and other system-wide difficulties. But if the business requirements are not properly understood first, then it can produce massive disruption and distraction with little prospect of any real benefit. This is where a clear business architecture is important. (Advice: Don't try to produce a new Responsibility structure without first understanding Activity, Capability and Motivation.) See my post on Organizational Integration.


Designing Reward Systems. An enterprise has many goals and subgoals. Some individuals and groups and subcontractors may be given incentives to deliver against particular targets. However, poorly chosen incentives can result in dysfunctional behaviour - local success but global failure. The relationship between local performance and global performance is another area where the business architecture


Management Accounting. Distribution of costs, benefits and risks depends on the dependencies between activities, capabilities, resources and other things. See my post On Business Architecture and Management Accounting.


Outsourcing and Procurement. Designing clean, robust and governable boundaries between the company and its suppliers.


Systems Architecture. Design of sociotechnical systems, including information and communication systems.


In many organizations, the most obvious purpose of business architecture is to drive systems architecture. However, this is not the only way that business architects can deliver value.

Historically, a  number of functional specialisms, including accounting, contract management and human resources, developed in an era when business structure was a lot simpler, so functional specialists didn't need to worry about architectural complexity. However, these specialisms may continue to make simplistic assumptions about business structure, and this can result in strategic error and dysfunctional organizations. Business architecture needs to engage actively with all these functional specialisms, to help align their efforts with the real and often complex requirements of the business.

---

Places are still available on my Business Architecture Bootcamp (November 20th-21st)

On Business Architecture and Management Accounting

Someone asked on Linked-In Should EA be knowledgeable about accounting and its pitfalls? Here is a rewritten version of my reply.


Management accounting provides a view of the distribution of costs, benefits and risks. Costs include labour costs, materials and other purchases, and so-called overheads. So if we want to know the total production cost of a particular product, or the total cost of a particular activity, we need to work out what share of the total expenditure should be allocated to this product or this activity. These calculations are important for many reasons, including deciding whether to invest in improved systems and technology, deciding whether to keep some capability inhouse or outsource, determining how profitable a given product or service is at a given price and volume.

In One Strategy One PL (January 2013), John R Moran argues that a company can only have a unified strategy if it has a single unified accounting view, and suggests that "the entire logic of profit centers rests on the assumption that maximizing the pieces will maximize the whole". Clearly the relationship between the performance of the pieces and the performance of the whole is an important topic for architects.

Accountants use various simple methods for cost allocation, including so-called Activity-Based Costing. These methods all make some structural assumptions about the dependencies between activities, capabilities, resources and other things. They also involve rules about handling expenditure spanning more than one accounting period. These assumptions also affect project evaluation (e.g. return on investment).

If these structural assumptions are simplistic or incorrect, the management accounting view may lead management to make poor decisions - for example, about investment or cost-cutting or outsourcing. (See my post on Architecture as Jenga.) So business architects need to appreciate what structural assumptions are implicit in the management accounts, and be prepared to challenge these assumptions when necessary.

This is not just because business architects should understand the structure of the business, but also because architecturally-led initiatives may depend on producing a business case that relies on a correct allocation of costs and benefits. For example, architects often wish to advocate long-term investment in shared services and platforms, but such investment may sometimes appear unattractive or unfundable when viewed from a conventional accounting viewpoint, and may be hard to get through the conventional budgeting process. If architects don't understand the potential distortion of the conventional accounting viewpoint, and allow management to take the accounting viewpoint at face value, then they are effectively ceding control of the business structure to the accountants.

Business architects need to pay attention to the structure of cost. Accountants allocate costs according to implicit (and often simplistic) architectural assumptions. For example, accountants use activity-based costing, based on a very simple activity architecture. If left unchallenged, these cost allocation rules can create difficulties for architects in establlshing the business case for shared services and shared infrastructure platforms, and other architecturally-led initiatives. This is one reason why architects need to take on the accountants rather than accept the accountancy view at face value.

See also my post on the Calculus of Cost. This is one of a series of posts on The Purpose of Business Architecture.

See also Tom Graves, Financial-architecture and enterprise-architecture (30 September 2013)

---

Updated 2 September 2013

The Illusion of Architecture

#bizarch #entarch @hspplease Following my post on the Resistance to Architecture within the National Health Service, I came across this cynical remark by Tony Riley of the Health Solutions Partnership.

"We really don't know why the term 'healthcare commissioning architecture' has become so closely associated with this reform. Architecture would give us the belief that detailed blueprints were being followed as is in the design of a building, a methodology that has scientific merit. When it comes to the Secretary of State’s healthcare reform there has been no blueprint detailed enough to prevent the chaos having been played out over the last year across the NHS commissioning and provider side with more to follow we suspect. So perhaps the illusion of architecture has been used to give us a false sense of reassurance." Tony Riley, Healthcare Commissioning Architecture. The UK Health Bill translated and implemented (Health Solutions Partnership, 2011)

Architecture is known for creating illusions (also known as visions), but (as Baudrillard pointed out) the ability to create illusions can also generate self-delusion.

Another well-known paradox of architecture is the conflict between architecting for the real world (complete with conflict and compromise) and architecting for a fantasy "theme park" world in which there is no place for conflict and compromise. In a 1997 book on Disney, this is called the Architecture of Reassurance. (This was also the title of a short film released in 2000.)

An implication of Riley's remark is that senior people within the NHS are paying lip-service to architecture as a substitute for actually doing any proper architecture. If this is true, it would explain the apparent reluctance to expose organizational designs for public and professional scrutiny. But I for one don't find this very reassuring.

Jean Baudrillard, Truth or Radicality: The Future of Architecture (1999)

Karal Ann Marling (ed), Designing Disney's Theme Parks: The Architecture of Reassurance (Abbeville Press, 1997). Review by Frankie Roberto (undated) See also Carnegie Magazine 1999

Mimi Yiu, Virtually Transparent Structures (2003).

At least three views of business architecture (TOGAF)

In a previous post, I looked at the five viewpoints of business architecture according to the OMG. In this post, I shall look at the architectural modelling viewpoints indicated in TOGAF 9.1. (Section 8.2). In TOGAF, these viewpoints are presented more as suggestions rather than as a recommended set.

1	Hierarchical Activity Models (also called Business Process Models)	Functions, data/information exchanges, activities, inputs, controls, outputs, mechanisms/resources, business rules	General
2	Use Case Models	Business processes, system functions, use case, actor,	General
3	Business Class Models	Information (entities and implementation classes, attributes and relationships), information behaviours	General
4	Node Connectivity Diagram	Nodes (role, org unit, location, facility), information transfer/flow	Defence sector
5	Information Exchange Matrix	Information Exchange	Defence sector
6	Resource-Event-Agent Model	Resources (goods, services or money), Event (transactions and agreements), Agent (people and organizations)	Accounting domain

According to TOGAF, "a variety of modeling tools and techniques may be employed, if deemed appropriate". Items 1-3 are offered as general examples.

Items 4 and 5 are described as follows. "Although originally developed for use in the Defense sector, these models are finding increasing use in other sectors of government, and may also be considered for use in non-government environments."

Item 6 is included in a list of "business models relevant to common high-level business domains". Whereas the other members of the list are specific industry models, the Resource-Event-Agent (REA) Model appears to be a modelling viewpoint - indeed Wikipedia calls it an ontology. TOGAF asserts that the REA model "has proved so useful for better understanding of business processes that it has become one of the major modeling frameworks for both traditional enterprises and e-Commerce systems", but this assertion is contradicted by Wikipedia which suggests that its main influence has been in the classroom and in the development of such standards as ebXML.

Wikipedia: Resources, events, agents (accounting model)


TOGAF's set of viewpoints strongly emphasizes the information processing and information exchange elements of business architecture, while neglecting a number of other elements that are included in the OMG five viewpoints or my own six viewpoints.

TOGAF lists a number of additional outputs from the business architecture work, which go beyond the modelling viewpoints it has specified. These are as follows.

Catalogs

Organization/Actor catalog, Driver/Goal/Objective catalog, Role catalog, Business Service/Function catalog, Location catalog, Process/Event/Control/Product catalog, Contract/Measure catalog

Matrixes

Business Interaction matrix, Actor/Role matrix

Diagrams 

Business Footprint diagram, Business Service/Information diagram, Functional Decomposition diagram, Product Lifecycle diagram, Goal/Objective/Service diagram, Use-case diagram, Organization Decomposition diagram, Process Flow diagram, Event diagram

Finally, TOGAF includes Business Scenarios, but I think this probably counts more as a requirements gathering technique than an architectural viewpoint.

I should welcome comments, especially from people who are familiar with TOGAF in practice.

Resistance to Architecture

A few weeks ago, I was at a meeting to discuss the UK National Health Service reforms. One of the speakers, a senior NHS administrator, used the word "architecture" in her presentation. Twice. Clearly referring to business/organizational architecture rather than physical architecture.

Encouraged by this, a couple of us approached her afterwards and asked her what kind of architectural work was going on, but we were treated with diplomatic hostility. (She didn't want to talk to us, and clearly wanted to escape as quickly as possible.) As far as we could make out, what she had meant by architecture was that she had some complicated organizational design in her head, but she definitely wasn't going to take the political risk of making this design clear to anyone else.

There may well be some proper business architecture work going on around the NHS reforms, but we have been looking for a while and haven't found much yet. (Which is a bit worrying, given the scale of the structural change that is underway.) If you know of anything I'd be delighted to hear from you.

There have perhaps always been individuals within large organizations who see some personal political advantage in maintaining obscure and complicated organizations that only they can understand and manipulate, and these individuals are probably always going to see good business architecture as a threat. But is there any reason why an organization as a whole should resist business architecture? Are there some organizations where that kind of small-p-political approach to management is so deeply ingrained in the culture that good business architecture is incompatible?

In his book, The Systems Approach and Its Enemies, C West Churchman identified four enemies of the systems approach: Politics, Ethics and Morality (the dominance of the "Big Idea"), Religion (irrational attachment to traditional forms), and Aesthetics (intuition, irrational optimism). Although as Churchman himself acknowledges, the notion of "enemy" is itself problematic from a systems perspective.

If politics may be one source of resistance to business architecture within the NHS, another source may be the "Big Idea", also known as "Principles". One of the reasons I am less enthusiastic about principles than many of my fellow architects is that I often see principles being used not as a starting point for hard work but as a substitute for it. In the public sector, we often see broad principles such as Choice or Competition being bandied about, with no serious attempt to work out how these so-called principles might work in practice. And if the structure and behaviour of the NHS is completely determined by these abstract principles, as some would have us believe, then there is obviously no point wasting time getting business architects involved. See my post On the misuse of general principles (Jan 2012).

A third reason for steering clear of business architecture might be because everyone believes that the fundamental structural problems are so deeply embedded in existing institutions that there is no point hiring business architects who will merely tell us what we already know. So we go on tinkering with the details, shifting responsibility for commissioning from one bunch of bureaucrats to another bunch of bureaucrats, but not making any real inroads into the institutional separations between primary and secondary care, or between healthcare and social care.

The final reason for thinking that business architecture is unnecessary is because of the Faustian pact with senior staff. The woman I heard talking recently presents an attractive and optimistic vision of transformation, plausible to nearly everyone except a few politically motivated snipers. And of course business architects. No wonder they regard us as the enemy.

See also The Illusion of Architecture (September 2012)

Is there a place for LOCATION in Business Architecture?

#bizarch #entarch Most enterprise architecture frameworks put LOCATION into the business architecture domain. So am I merely being contrarian when I ask whether it really belongs there?

My first point is that some IT people may regard the business architecture domain as a dumping ground for anything that doesn't belong anywhere else. For example, TOGAF 9.1 includes a skills matrix and set of job descriptions in the business architecture (Chapter 8), and I found a framework called Lite EA that includes staff demographics. There is perhaps an idea that the business architecture includes all non-IT aspects of the solution architecture, including physical processes as well as human activity.

My second point is that business architecture doesn't just mean a complete collection of business-oriented IT requirements. Maybe some of the staff work from home on Fridays, and this has some important implications for IT systems and infrastructure, including security. However, people sometimes working from home does not affect the structure and behaviour of the business, so it's not really business architecture.

My third point is that a lot of these frameworks have evolved from earlier work, dating from an era when geography was (a) more significant and (b) more straightforward.

My fourth point is that there are some aspects of geography that may be indirectly relevant to business architecture. For example, the concept of jurisdiction - which set of laws and taxes apply to a given asset or transaction - although large firms employ armies of lawyers and accountants to quibble such matters. And many organizations define responsibilities semi-geographically - for example, which country manager or regional manager owns a given asset or transaction. However, these are often complicated by cross-border arrangements, especially between global enterprises, and cannot be automatically derived from geographical location. Even if we are interested in geography in the business architecture domain, it serves primarily as a classification rather than a set of elements.

My final point is that physical location belongs to an entirely different domain, which I want to call Physical Architecture, which might include office facilities, storage facilities, transport links, and suchlike. These are clearly necessary for the implementation of a particular solution to a geographically distributed business process, just as the computing and communication facilities are, but they aren't part of the business architecture.

---

This post has prompted two questions on Twitter.

Eric Stephens asked Are locations/buildings just tech? My answer: pretty much, yes. Le Corbusier said that a house was a machine for living in.

Alex Matthews asked Are you also going to separate time as a domain? My answer: I see neither time nor space as architectural domains, but as dimensions affecting one or more architectural domains. Clearly time affects several domains. The argument here is whether the business architecture domain is significantly affected by the spatial dimension. I don't think it is.

Towards a metamodel of business architecture ...

#bizarch #entarch I have been challenged to explain the constructs underlying my Six Viewpoints of Business Architecture (blogpost, draft book), so here is a rough schema. Comments please.

Viewpoint	Key Elements	Structure / Behaviour / Function
Purpose View Motivation View	Goal, Influence (Cause-Effect), Stakeholder, Outcome, Value	Goals and outcomes are linked by chains of influence or production. A goal aims at an outcome, one outcome influences another (positively or negatively), therefore one goal supports or opposes another goal. From the Business Motivation Model (BMM), I include here Ends, Means and Influencers, but not Directives (which I include in the Cybernetic View) Some people like to arrange goals and objectives as a hierarchy ("Aim Hierarchy"). Alternatively, influence chains can be drawn as a network, using a notation such as i*.
Activity View	Activity, Event (Condition/Trigger), Interaction, Outcome, Role, Work	Activities are linked by process chains (sometimes called value chains/streams)
Capability View	Activity, Capability, Component, Value, Work	Components perform activities according to some abstract capabilities. Capabilities and components are linked by chains of dependency.
Knowledge View	Concept, Event (Fact)	Concepts (represented by entity types or classes) are linked by facts (represented by relationships and attributes). Simple and compound facts are linked by chains of inference or derivation.
Responsibility View	Agent/Role, Outcome, Responsibility, Service, Stakeholder	Agent/Role is responsible (accountable) to a stakeholder (or stakeholder proxy) for some outcome. Responsibilities and services are linked by chains of delegation. Among other things, the Responsibility View allows us to view the Principal/Agent problem (which applies at every level of the management structure).
Cybernetic View	Component, Control, Event (Signal), Regulation/Rule (Directive).	Components are governed by regulations/rules, and are linked by control loops or feedback loops. Some people like to arrange policies and rules as a hierarchy ("Directive Hierarchy").

Some important notes.

Firstly, note that some elements appear in more than one viewpoint, but they don't look the same. 

For example, in my schema an event appears in the activity view as a condition or trigger for one or more activity, in the knowledge view as a fact (e.g. a piece of information reporting a change of state), and in the cybernetic view as a signal (allowing control and regulation). The knowledge view defines the semantics of the event (what it means in conceptual terms); the activity view and the cybernetic view define the pragmatics of the event (what it means in behavioural terms).

Secondly, I am not ready to claim any universal applicability for this schema. I am aware of various paradigms that have particular (and conflicting) definitions for these terms, and I am not trying to accommodate every possible meaning of every term.

For example, I am aware that some paradigms have a slightly different notion of event. I am also aware that some paradigms regard a signal as an output (from a management information system) rather than as a control flow (into some management process).There are also conflicting views whether we should regard capabilities as abstract or concrete. (For this reason I have removed the word "abstract" to which David's comment refers.)

Thirdly, each viewpoint allows for both hierarchical and network structures. Although my own preference is to draw networks rather than hierarchies, I am not dogmatic about this.

Fourthly, there are some things I don't regard as part of the Business Architecture but as part of some other domain. These include Location, Requirement, Solution, System (including Human Activity System or SocioTechnical System), Transformation and Use Case. I shall try to justify these exclusions in a separate post.

And finally, I am aware of how much work would be required to turn this into a rigorous ontology or metamodel. If anyone is interested in funding this work, please send me a large cheque.

The Cybernetic View

#bizarch One of the Six Views of Business Architecture is the Management View or Cybernetic View. To understand this view, let's start by asking what kind of thing management is.

One way of thinking about management is as a particular bundle of capabilities, such as planning, resource allocation, monitoring and control. These capabilities can be mobilized according to some routine schedule of activity (for example, the annual budget cycle), or in response to various events inside and outside the enterprise. So we can view management from a Capability viewpoint, or from an Activity viewpoint.

Another way of thinking about management is as a particular bundle of role and responsibilities. These may be presented as a hierarchy or matrix, although such depictions are usually highly simplistic. Management responsibilities may be controlled by a select group of senior staff, with "manager" or "director" or "officer" in their job title. Alternatively, they may be wholly or partially distributed to other staff along with various operational responsibilities. In any case, the real (defacto) distribution of roles and responsibilities is usually much more subtle and flexible than the official (orgchart) distribution. (cf The Four Organizations of Lord Brown.)

We may therefore view management at different levels of abstraction - either specifying the concrete division of responsibilities between named roles or even named individuals, or merely identifying the total set of responsibilities without allocating them to specific roles.

Both the Capability view of management and the Responsibility view of management are useful, but neither of these viewpoints really captures what is distinctive about management. Instead, we need to turn to a systems view of management, inspired by such thinkers as W. Ross Ashby, Russell Ackoff, Stafford Beer and Gregory Bateson. Let's call this the Cybernetic View.

The Cybernetic View is based on the idea of goal-directed behaviour, based on feedback and feedforward loops. This is elaborated into various frameworks, including Stafford Beer's Viable Systems Model (VSM).

A conventional interpretation of the Viable Systems Model is that it models an organization from the viewpoint of a neutral and all-seeing observer. The cybernetic literature can be divided into First-Order Cybernetics, which accepts this interpretation, and Second-Order Cybernetics, in which the position of the observer is itself problematic.

Bateson's work on Second-Order Cybernetics has directly or indirectly inspired many generations of management and organization scientists, including Chris Argyris, Donald Schön, Kenwyn Smith and Peter Senge, and I have used many of their ideas in my own framework for Organizational Intelligence. Some researchers are currently exploring Third-Order Cybernetics, but this is not yet mainstream.

The Cybernetic View should also embrace Robert Rosen's concept of Anticipatory Systems -

"A system containing a predictive model of itself and/or its environment, which allows it to change state at an instant in accord with the model's predictions pertaining to a later instant." Wikipedia

The Cybernetic View provides a useful complement to a conventional process view. As I pointed out in my post on Collaboration Impact Zones, AS-IS models can often be incomplete descriptions of reality, because they fail to document all the informal communication and coordination mechanisms that keep the business running. One way to discover these missing elements is to analyse the AS-IS models according to cybernetic or statistical principles, which may allow us to infer the existence of some coordination mechanism, even though we don't have any visible evidence of coordination taking place.


See also my earlier post Organizations as Brains.

My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/

---

Important note - I haven't read all of these papers myself yet, so I'm putting them here for my own reference as well as yours. Update: Professor Vidgen kindly dug out a paper he wrote ages ago. 

Sabine Buckl, Florian Matthes, Christian M Schweda, A viable system perspective on enterprise architecture management. 2009 IEEE International Conference on Systems Man and Cybernetics (2009)

Gil Regev, Ian Alexander, Alain Wegmann, Use Cases and Misuse Cases Model the Regulatory Roles of Business Processes. Business Process Management Journal, "Goal-oriented business process modelling" Guest Editors: Ilia Bider and Paul Johannesson Volume 11 Number 6 2005 pages 695-708

Richard Vidgen, Cybernetics and business processes: using the viable system model to develop an enterprise process architecture. Knowledge and Process Management, 1998.

Anders Jensen-Waud, Paradoxes in EA and Systems Research (April 2010)

Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Mapping the Enterprise Architecture Principles in TOGAF to the Cybernetic Concepts--An Exploratory Study (2012 45th Hawaii International Conference on System Sciences)

Mohammad Esmaeil Zadeh, Gary Millar and Edward Lewis. Reinterpreting TOGAF’s Enterprise Architecture Principles Using a Cybernetic Lens (Journal of Enterprise Architecture, May 2012)

Six Views of Business Architecture

#bizarch Does it make sense to produce a business architecture from a single viewpoint, such as a Process Viewpoint or a Capability Viewpoint? Or do we need a proliferation of viewpoints, perhaps arranged in a 2x2 matrix such as the Zachman Framework?

In its Business Architecture Overview, the Object Management Group Business Architecture Working Group has identified five key views of a business, which it calls 1) the Business Strategy view, 2) the Business Capabilities view, 3) the Value Stream view, 4) the Business Knowledge view, and 5) the Organizational view. See my previous post on the Five Views of Business Architecture (OMG), in which I also identify a sixth one, which I've been calling the Management or Cybernetic view. (Strictly speaking these are viewpoints rather than views, but I'm trying to stick to the OMG terminology as far as possible.)

I have used all of these views for business modelling, and I am convinced that they are all useful - although they may not all be required on every project. (I don't expect you to believe this without further evidence, and I am currently assembling a set of worked examples.)  I have presented earlier versions of this schema in the past, with slightly different names, but I believe the current names and explanations are clearer.

Business Motivation View (aka Purpose)

This viewpoint describes what the business achieves for itself and its stakeholders (direct and indirect value). It specifies desired, potential and actual performance in terms of goals and objectives as well as positive and negative outcomes. (For example, a risk is a potential negative outcome.)

Outcomes may be described qualitatively or quantitatively, and there are different analysis techniques and notations associated with the transition from quantity to quality.

A more sophisticated view would consider the uncertainty associated with these outcomes, as well as the potential conflict between the goals and values of different stakeholders. It would also recognize that there is often a subtle difference between the official or espoused goals and objectives of an enterprise and its defacto goals and objectives. See my post on Enterprise POSIWID.

The OMG calls this the Business Strategy view, but I think this is a misleading name. The strategy doesn't reside in motivation, but in how the business mobilizes itself to satisfy some set of motivations.

The name Business Motivation view reflects the Business Motivation Model (BMM), which provides some limited coverage of this view. Alternatively, I could call this the Business Performance view.

Business Capability View (aka Component)

This viewpoint describes how the business delivers direct and indirect value in response to the challenges of the environment. Many business architects merely decompose the business into something that looks like an old-fashioned functional hierarchy, but there are several important architectural issues that need to be addressed within the business capability view.

• Coordination of internal and external capability. When an organization chooses to delegate or outsource a particular capability, the coordination of the outsourced capability remains.

• Capability dependencies - how strength or weakness in one capability affects the performance of other capabilities.

• Requisite variety. An organization chooses what range and variety of events it is capable of responding to, and this variety is reflected in specific capabilities.

• Through-life capability management. Establishing a capability requires some level of investment, in terms of equipment and recruitment and training and so on. The costs of maintaining a capability may escalate, especially if the demands keep changing.

• Performance, quality and value-for-money. It is always possible to devote more energy and resources to improving any given capability, but this is only justified if it is reflected in business performance (aka "the bottom line"). Business excellence models (such as Baldrige and EFQM) address this kind of alignment.

Capabilities may be encapsulated in what I have called Business Components, as in my 2001 book on the Component-Based Business. Thus we could also call this the Component View.

Business Activity View (aka Process)

This viewpoint describes the day-to-day behaviour of the business, or what the OMG calls "business in motion". Traditionally processes are seen as a chain of value-adding process steps, thus the OMG calls this the Value Stream view. However, the value network paradigm looks significantly more powerful than the value chain paradigm, and I prefer to use the neutral term Business Activity.

Business Knowledge View (aka Concept)

This is a well-established architectural viewpoint, previously known under various names such as Conceptual Information Model or Business Data Architecture. It basically captures what the business knows, and the semantics of how the business talks to itself and its partners. This viewpoint is critical for business interoperability. Knowledge also includes contextual knowledge, which is essential for providing differentiated services.

At this level, I'm not distinguishing between data, information and knowledge. Classifying information as "structured" and "unstructured" is not as important to the business architecture as it is to the IT architecture. What is important, however, is the question of business epistemology - what it is possible for the business to know, and with what level of confidence. There are various sociotechnical mechanisms that may make it possible for a 21st century business to know all sorts of things that were simply not available before. But of course, the business architect is not directly interested in the mechanisms themselves - these belong to some other architecture.

Responsibility View (aka Organization or Relationship)

The OMG defines an organizational view in terms of the relationships between organizational units, so I think the term Responsibility View is a better name for this view. I have done a lot of work on business relationship modelling, looking in particular at questions of the organizational responsibility and accountability for activities and outcomes, and this work can be traced back to the ORDIT methodology of the early 1990s. These relationships and organizational interfaces may be represented as services, with various levels of formality in defining and measuring service levels. There are also important architectural issues in dealing with the idea of Business-As-A-Platform, in particular in relation to multi-sided markets.

Cybernetic View (aka Management or Governance)

Finally, the cybernetic view describes how the organization and its management thinks. This covers all the aspects of organizational intelligence, from information gathering, through sense-making and decision-making, to organizational memory and learning.

See separate post on the Cybernetic View.

Hybrid Views

These views are not sacrosanct, and there are some useful business models that may not fit neatly into these six viewpoints. For example, Martin Ould's Activity Role Diagrams seem to involve a combination of Activity and Responsibility, while Stafford Beer's Viable Systems Model combines the Capability View and the Cybernetic view.

I am also convinced that business strategy is not contained within a single view (as the OMG would have it) but is about the relationships between the views.

Levels of Abstraction

Each of these viewpoints can be applied at different levels of abstraction. For example, in business relationship modelling, we may identify a partner-independent model (which merely defines an abstract relationship with a notional business partner) and a partner-specific model (which defines a concrete and contractual relationship with a real business partner).  Meanwhile, in the capability view we may need to distinguish between abstract capabilities (which some frameworks regard as the only true capabilities) and sociotechnical lumps that implement these capabilities (which may be called components or nodes).

This relationship between abstract and concrete is what Zachman calls reification, and everyone else calls realization. Note that both the partner-independent model and the partner-specific model belong to the business architecture and not to any other architectural domain.

---

My booklet on Business Architecture Viewpoints is now available in draft on the LeanPub platform. http://leanpub.com/businessarchitecture-viewpoints/

Perspective in Depth

As the systems thinking pioneer Gregory Bateson pointed out, there is an important difference between seeing with one eye and seeing with two. With monocular vision even the much prized Big Picture can be merely a flat and featureless panorama. Binocular vision affords a sense of depth and contour, and enhances the view.

When I wrote recently about the "What the Business Wants" viewpoint, Nick Gall challenged me to state whether I was referring to nominal purpose or defacto purpose (POSIWID). My answer was that the "What the Business Wants" viewpoint gave us a vantage point from which we could view both nominal purposes and defacto purposes at the same time, and appreciate the rich dependencies and contradictions between them.

So what happens when I apply the same thinking to the other five viewpoints? Each viewpoint has a monocular version (simple, linear) and a binocular version (rich, multi-dimensional). Here are a few key differences.

		Flat	Rounded	Links
Strategic View	What the Business Wants	Nominal purpose Nominal strategy	Defacto purpose Emergent strategy	Enterprise POSIWID
Capability View	How the Business Does	Operational capability Hard dependencies Top-down leadership	Sociotechnical capability and competency Soft dependencies Edge leadership
Activity View	What the Business Does	Linear synchronous process (value chain)	Asynchronous collaboration (value network)	Changing Conceptions of Business Process
Knowledge View	What the Business Knows	Formal information systems	Informal information systems Sensemaking Appreciative systems
Management View	How the Business Thinks	Goal-directed behaviour Management by objectives Single loop learning First order cybernetics (VSM)	Second-order cybernetics (Bateson/Maturana) Double-loop and deutero learning	Organizations as Brains
Organization View	What the Business Is	Enterprise	Business-as-a-Platform Ecosystem

But how should I label the two columns? Should I succumb to the temptation to label the first column "traditional"? Any suggestions?

Organizing Business Capabilities

#entarch #bizarch Following a Linked-In discussion on business architecture and capability modelling, I was slightly alarmed to see how many contributions to the discussion were based on an argument from authority: IBM says this, Michael Porter says this, Forrester/Gartner says this.

Obviously these are all clever guys, but does that mean they have all the answers? Someone claimed that IBM's model was based on something called "natural clustering", but I don't know what he thinks that means. The only clustering I've ever seen used in architectural contexts has been artificial, meaning that what you get from clustering depends a lot on what algorithm or mechanism you use, as well as when (at what stage in the process, the level of granularity) you choose to carry it out.

In any case, I am sceptical of generic architectures. If I want a house that is exactly the same as everyone else's house, I don't really need an architect at all - I just need a structural engineer to calculate the strength of the beams and align the plumbing. I don't expect an architect to spend months just giving me a slightly modified copy of something he found in a textbook.

I think the interesting question is how to derive a capability map from the particular behaviours of an organization and the particular intentions of its leadership, rather than just imposing some off-the-shelf business school or vendor nostrum.

So, what kind of capability map do we need to understand the organization of capabilities? Many people think all we need to do is identification and classification - decomposing the enterprise into a set of independent capabilities. Business analysts can then document each capability separately (I sometimes use a capability canvas that is adapted from Osterwalder's business canvas), decide which capabilities are of greatest strategic importance, and produce a plan for business improvement. (The UK MOD practises a methodology called Through-Life Capability Management, and a casual Internet search will identify several large consultancies and systems houses that claim expertise in this area.)

This is all well and good, but it misses what I regard as the critical architectural point - the relationships between capabilities. Business analysts may be happy with capability decomposition, but I think business architects also need a capability dependency diagram, which shows, among other things, how one capability creates or modifies, coordinates or governs other capabilities. Many of the popular capability modelling methods concentrate on modelling the operational capabilities only, but I prefer to produce a model that includes the higher level development and management capabilities.

Fans of Stafford Beer's Viable Systems Model (VSM) will regard the operational capabilities as corresponding to what Beer calls System One, while the higher level capabilities correspond to Systems Two through Five. (For many purposes, I find a simpler three-level schema is enough.)

Another schema for modelling different classes of capability can be found in the draft Systems Engineering Body of Knowledge: Enterprise Systems Engineering Background. This schema is useful in recognizing the distinction between operational capabilities and other classes of capability, but I think it is limited by its strong engineering bias and is probably insufficient for the purposes of business architecture.

Marketing genius Seth Godin once reported a conversation with a publishing executive: "People ask me what the hardest thing is... is it finding authors? I tell them that the two hardest things are hiring great people and watching the cash flow." [The Hardest Thing, April 2006] Things like these are not just hard but critically important to the success of an enterprise - because so many other things are dependent upon them.

It is these dependencies that the business architect must understand - in order to see how improvements in one area may or may not ripple through the rest of the organization, sociotechnically as well as technically. That's why I think capability mapping is more than just engineering.

Conceptual Modelling - Why Theory

@dougnewdick asks Why Bother With Concepts? In his answer, he quotes the Gang of Four song Why Theory. Each day seems like a natural fact/but what we think changes how we act.

I think there is a critical difference between two interpretations of the term Conceptual Architecture. I'd describe Doug's sample conceptual architecture as essentially a component architecture, which happens to be at the conceptual level of abstraction. In other words, it provides a conceptual understanding of how the components work together.

That's not at all the same as understanding how the concepts themselves work together, which is what I think one needs to satisfy the Gang of Four requirement for an architecture-of-concepts, and which would also be implied by Doug's reference to the Wikipedia article on Philosophical Analysis.

The Wikipedia article mentions critiques of the traditional approach to philosophical analysis by Quine and Wittgenstein. I have used some of their ideas - although with no claim to profundity - in my own approach to conceptual modelling. See for example my 1992 book on Information Modelling.

To take a concrete example, if we are going to build systems and management practices to anticipate competitor behaviour, it might help have to have a robust concept of COMPETITOR. I once worked with a company that thought it knew which its competitors were, and were quite indignant when a competitive threat appeared from an entirely different quarter. Traditional philosophical analysis implies you can fully characterize a concept like COMPETITOR in advance, but Wittgenstein and Quine teach us to be cautious of monothetic, appearently objective conceptual definitions.


One of the problems with conceptual models is that they are often too generic, and therefore insufficiently meaningful. Anyone who has ever been on a data modelling course can produce a model with CUSTOMER and ORDER and PRODUCT. But proper conceptual analysis entails taking concepts apart to understand how they work in a particular business context. Where do products come from, what does it mean to be a product, how do products evolve, what are the essential and non-essential differences between products? Why do we have this many products, and what are the forces that would result in increasing or decreasing the number of products? What does the business know about products, and what does the business want to know?

Doug's post was prompted by Peter Bakker's post Factual Architecture, which expressed a concern that concepts can be too abstract and unverifiable – failing to connect with audiences, failing to connect with reality. The way that some architects try to verify concepts is to demonstrate how the concepts could be represented in some technical system - but I prefer to encourage stakeholders to verify concepts in the business domain itself. This leads me to a slightly different notion of Factual Architecture, which would provide an empirical business context in which the business concepts and knowledge can be grounded.

Is this really the way it is? Or a contract in our mutual interest? (Gang of Four: Contract)

See also Big Data and Organizational Intelligence (November 2018)

Five Views of Business Architecture (OMG)

#OMG #BAWG The Object Management Group Business Architecture Working Group has identified five key views of a business.

1. the Business Strategy view ("What the Business Wants")
2. the Business Capabilities view ("What the Business Does")
3. the Value Stream view ("How the Business Does")
4. the Business Knowledge view ("What the Business Knows", "How the Business Thinks")
5. the Organizational view ("What the Business Is")

Source: Business Architecture Overview

While working with the CBDI Forum between 2002 and 2009, I developed an approach to business modelling for SOA, which included an emphasis on decoupling the WHAT (what the business does, what the business knows) from the HOW (how the business does). We felt that this decoupling provided the best basis for managing differentiation and integration across complex enterprises, and for achieving appropriate economics of scale and scope.

In my more recent work on Organizational Intelligence, I have sought to further decouple "What the Business Knows" from "How the Business Thinks". Different enterprises operating in the same ecosystem may be able to share a lot of common knowledge and information, but may each arrive at different judgements about What-Is-Going-On.

I shall be presenting the latest version of this schema in my Business Architecture Bootcamp and Organizational Intelligence Workshop, and explore how this schema helps to address a range of practical business problems.

---

 book now  Business Architecture Bootcamp (November 22-23, 2011)
 book now  Workshop: Organizational Intelligence (November 24th, 2011)

Business Architecture Bootcamp

Most courses in business architecture (or any other methodology for that matter) start by teaching a set of generic principles, followed by a standard set of tasks and techniques. The tasks and techniques are then illustrated by some simplistic or contrived examples and exercises. Video store, anyone?


In my forthcoming business architecture bootcamp (Unicom Middlesex, November 22-23), I'm going to lead an exploration into some serious and non-trivial business problems, based on some real experience in a real company. The class will experiment with different ways of modelling these problems, spanning the Five Views of Business Architecture, in order to go deeper and deeper into an understanding of these problems and their architectural implications. I don't know exactly where we shall end up, but I am confident that this is a better way of learning the things that really matter to business architects.

---

 book now  Business Architecture Bootcamp (November 22-23, 2011)
 book now  Workshop: Organizational Intelligence (November 24th, 2011)

Early bird rates available until November 1st.