Positioning Business Architecture

Popular Enterprise Architecture methods position Enterprise Architecture, including Business Architecture, within I.T. and reporting to the CIO or CTO. This reflects the history of how EA methods have arisen: initially addressing Technology, then Applications and Data. As I.T. became more strategic and vital to business and businesses realised they needed alignment with I.T., management of costs and risks, the Business Architecture domain was added or expanded.

For most current EA methods, this is very much I.T. looking at the business to understand the organisation structure, processes and (maybe) value chains and capabilities which I.T. should enable and support. This may be OK for Enterprise I.T. Architecture, but is not true Business Architecture. The latter should be architecting the business and its future within the context where it operates. Given this perspective, Business Architecture should be outside of I.T., possibly in a Strategy or Business Change area. It should report to the Chief Strategy/Change/Executive/Operations Officer. Some advanced organisations now have a Chief Architect at ExCo level, responsible for all aspects of change and future planning.

The danger if Business Architecture reports to I.T. is that the agenda and priorities will be driven from this perspective. We watched this happen in a client organisation. They had a fairly new but competent Business Architecture function which was working well and initiating and guiding strategic change. The I.T. function was not performing as well and they hired a new high powered CIO to take that over. He lobbied hard and was successful in bringing the Business Architecture function under his control. Within two years it had lost all effectiveness as an agent of strategic business change.

By contrast we assisted another client to establish an EA function, and a Business Architecture competency from scratch. The Business Architecture function reported directly to the Office of the CEO, who was also its sponsor. A PMO was set up to drive the change projects, and the triumvirate of Business Architecture, PMO and IT (Including Enterprise I.T. Architecture) proved highly effective in driving a major strategic transformation programme including many non-I.T. aspects over a period of three years (and ongoing).

The diagram indicates how pivotal a good Business Architecture function can be. It informs the other architectures below it to ensure alignment. It drives business initiatives, which deliver competencies to operate the business.

The picture, of a lookout post in Israel, is a bit more tongue in cheek. It illustrates the current position of many Business Architecture functions - high up, but precarious!

#BusinessArchitecture #Strategy #EnterpriseArchitecture #StrategicAlignment

Satisfied Stakeholders

A stakeholder is someone (person, entity) that has an interest in the outcome of something. An investor in a business is a stakeholder, as are its CEO and its suppliers and its staff members. A sponsor in a project is a stakeholder, as are the people who will use the resulting system and maintain it. Stakeholders have different perspectives, motivations and expectations. Often, we will rely upon stakeholders for things that we want: investment, information, participation, approval, support, resources… So, it is really important to identify stakeholders, keep them engaged and to meet their expectations (within reason and without compromising our own goals).

Another reason to really keep an eye on stakeholders is this: If we are a business, we prosper to the extent that we continue to deliver value to our stakeholders; delivering that value requires capabilities, which in turn rely upon people, processes, systems, data, technology etc. So this guides where we put our focus and what we need to optimise in our business and enterprise architecture.

From a project perspective, our stakeholders are providing inputs (money, information, resources etc.) with the expectation of some desirable change or result (e.g. a new process, product, system etc. ). To produce the outputs that they require, we will need to carry out various tasks, apply skills, resources and effort to produce various artefacts. If we pay attention to what stakeholders need, we can translate that to product models (configurations of deliverables if you like), the tasks required to produce them, and the people, skills, resources and tools needed to perform the tasks. So, stakeholders can lead us directly into good project plans.

A technique we have evolved to rapidly analyse stakeholder interaction is the Stakeholder Net Value Exchange. This puts an enterprise or project in a central “black box”, surrounded by Stakeholder Types (e.g. Customer) & some important independent Stakeholders (e.g. Industry Regulator). We connect the stakeholders to the entity via edges in the direction of Value flow. You can think of these relationships as Stakeholder provides Value to Entity (inbound) or Stakeholder expects Value from Entity (outbound). For a compact diagram, the value can be recorded as text on the arrow. For a richer diagram (where we can start to see commonality etc. and define values more deeply) we put a Value symbol on the flow.

It is really illuminating to see an Enterprise or a Project from this perspective. It is also possible to model more than one collaborating entity this way, e.g. ourselves and a strategic business partner.
More detailed analysis easily ensues: We need to include all the Stakeholder types as concepts in our Domain Model; We can contemplate what Business Events occur with each Stakeholder, what Business Communication results and which Processes support them.

#Stakeholder #projectmanagement #enterprisearchitecture #businessarchitecture

Agile Process or Artefact?

There is much hype around Agile these days. We know that things are moving faster than ever and that “slow business is no business”.

There are agile methods, agile techniques, agile projects, agile best practices, agile coaches and agile certifications. But how many agile businesses are there?

I support the original tenets of the Agile Manifesto and the teachings of the founders. They highlight user involvement, refinement through iteration, communication, flexible working and trust relationships between business and technologists. All good things.

I do have a problem with agile dogma and religion in the absence of other essentials for Agile practices to work. These essentials include: high skill, small teams, continuity of resources, trust and attention to quality and testing. Agile should also not be used as an excuse to bin architecture, requirements definition and documentation.

I often see Agile abused to “crank the handle harder” in development projects in an attempt by business to get to functional goals earlier. The emphasis here is wrong. We don’t need a more pressured process, we need a better result: higher quality (better matching requirements) and more adaptable to future requirements.

Using a building analogy, many Agile projects are “laying bricks faster”. This may be without fully understanding requirements, proper design for safety, scalability and still creating a “fixed” artefact, namely a brick and mortar building. If requirements change, as business evolution dictates they will, another project is required to break down elements and build others.

I suggest we should be building more flexible artefacts. Take a conference centre, which must host a sports match one day, a book fair the next, on the weekend a rock concert and the following week a motor show. We know it has to be flexible and that we won't have time to rebuild. Flexibility is thus a stable requirement. Knowing that, we can design and build for it, even using a conventional construction approach. We can build a shell with large open, reconfigurable spaces, movable walls, power outlets in the floors, lighting on tracks, etc. This will allow the user community to alter the building themselves in a matter of hours.

We need Architecture to identify high level stakeholder requirements and change dimensions and try out conceptual options rapidly, partition elements that can be tackled by separate teams with defined interfaces and then to guide implementation. The construction itself could be agile or conventional. The former offers advantages where some requirements and suitable solutions are not known and need to be tried, prototyped and refined. Using an Agile approach requires high skills, stable teams, continuity of resources as well as a high trust from sponsors.

The solutions should be documented so they are easily used by the operators and maintainable for adaptation.

#Agile #SolutionArchitecture #EnterpriseArchitecture

Data Models in Business Architecture? Sure!

Many argue that data considerations are too technical for the business and should be the preserve of data and information architects or data scientists. However, current wisdom says that data is a business asset from which we should gain value and strategic advantage. Data ownership and responsibility should vest in the business, with IT being custodians and curators.

How do we resolve this paradox? Simple: its a T-shaped problem. Business Architecture is at a high level of abstraction, broad in coverage, but not detailed in depth. It is the horizontal bar of the T. Information Architecture is like the stem of the T. It has a number of layers of abstraction, including subject areas, conceptual models, logical models and physical models. Alongside those is meta data to map between the layers, cross reference usage, communities, implementations, security, ownership and myriad other concerns.

The overlap between the vertical and horizontal is where data should be in business architecture, as a Domain Model. This is at a conceptual level and includes the concepts of importance to the business. The Domain is the “subject of discourse”, in practical terms, the industry, such as Telecommunications, Retail, Manufacturing, Education or Health Care. The Domain Model should cover all relevant business concepts, but not include any technology specific details, or detailed requirements. It’s the 3000 metre view of data.
It should include: Concept Names, Definitions, Sample Instances, Identifying Properties, Relationships (Type/SubType, Containment, Association, Role). It may contain cardinalities/ratios, but these are not essential. Concepts can be grouped into useful subject areas, such as Finance, Product, Customer, etc. There should be a graphical view and a business glossary. It might be derived from or aligned to an industry reference model.

So what do we do with it? Lots! It is a Rosetta Stone to facilitate accurate communication between business communities and from there to technical communities. It gives us the nouns for our discussions around ownership, sharing, privacy, security, archival, requirements, business rules and more. It allows us to track progress w.r.t. data automation, migration, sharing, security, privacy management and metrics and quality. It facilitates consensus and integration. It helps to prevent duplication and integrity problems. It helps us leverage data as an asset and provides the platform for digital transformation.

#businessarchitecture #dataarchitecture #enterprisearchitecture #conceptualmodel

The Essence of Architecture

I am always astonished how many architects I meet who don’t know where the term comes from!

Way back when, wooden buildings were the norm for larger structures. They had issues such as rot and susceptibility to fire, but seemed to be the most available means of creating useful spaces with a reasonable amount of available material.

Stone was attractive because it was durable, non-flammable and available, but building large structures was near impossible because, as the size increased, the amount of stone, and the weight, increased as the cube of the dimensions. For a lintel across an opening, or a beam under a roof, the length was very limited before the weight became ridiculous and structures would collapse under their own weight. You could of course build a very large, almost solid, structure such as a pyramid, but that provided very little usable space for a huge investment of resources and effort.

Then someone invented the arch. This is very powerful, as the material doesn’t carry the weight, but transfers it downwards, finally to the ground. People who knew how to build arches became known as “architects”* and were sought after to allow the construction of large buildings (like courts, cathedrals, halls and civic buildings) and structures (like bridges, viaducts and aqueducts). Advantages included utility of the resulting structures, durability, reduction in materials required and elegance.

So, as architects, we should strive to deliver things of value and utility, with less resources, more quickly. The things we deliver should meet the requirements of their sponsors, delight their users, be durable and safe and make use of readily available resources. We could also add that the resources should be able to be replenished or recycled and that the result of our work should have minimum negative impact on its surroundings, while integrating seamlessly into its context. Finally, the inclusion of building in the scope means that the job is not done when the plan is drawn, but when the solution is delivered and usable.

*The word archi comes from the Greek arkhi and means a chief or leader. The tect part comes from the Greek tekton meaning builder. So an architect is a master or chief builder. There is also arc in Old English, meaning a curved or bow shape. Interesting that master builders also build bow-shaped arches!

#Architecture #EnterpriseArchitecture #Etymology

A Contrary View on Capability

Capabilities are fashionable. Everyone is modelling them, but not always well… And just what is a capability?

Popular business and EA methods use it more or less interchangeably with a “Business Function”, i.e. something we do. I differ.

Capabilities are often listed below a value chain/network to support the delivery of the value adding steps. This is all well and good. Often stated in simple phrases such as “Attract Talent”, “Create Desirable Products”. In this form they are equal to business functions. Less usefully, they will sometimes be stated as nouns, e.g. “Human Resources” or “Accounting”. These are vague at best and equate more to organisational units or departments.

Other methods include goal, process and service modelling. How do we make sense of all these? Are they competing or complementary?

One technique useful for all of them is decomposition - breaking down higher level goals / concepts / requirements to more detail or more concrete ones.

We can decompose Mission into Goals and Objectives; Mission into Functions; Processes into sub-processes and activities; Services into service components, etc. Can they be integrated? Fortunately, yes! Mission, Goals and Objectives are about what we want to achieve, independent of what needs to be done or how. They can provide a starting point for our decomposition. One mission breaks down into goals (broad directions) which break down into objectives (specific, measurable, achievable, realistic, time bounded). Mission (or objectives) can also be decomposed into functions: what must we do to achieve the goals? Functions should have a verb (doing something), an object (to what?) and qualifying clauses (how, with what constraints).

Functions can be sequenced on dependencies to form end to end business processes. Functions and processes can be packaged as services, with providers (who does it?), consumers (who uses it?), inputs (what is necessary to do it?), outputs (what is expected as a result?) and service levels. We need a catalogue of available services, and a designated way to invoke them.

Ah, but what of capabilities? Well, functions, processes, services can all deliver capabilities. A capability implies the ability to do something (function) for someone/thing (consumer) producing a desired result (service/product) at a particular location, with a certain service level (e.g. volume, efficiency, accuracy, etc. ) and potentially other requirements (e.g. in a particular language). To deliver a capability will typically require resources, such as skill, information, application support, infrastructure and physical presence.

There is nothing wrong with defining business functions (proto-capabilities) at a high level below the value chain. We should ensure, however, that they are expanded into full capabilities during later design to deliver all the dimensions required.

#Capability #EnterpriseModelling #BusinessModelling #EnterpriseArchitecture

Role of the Repository

As architects we use many models and produce/share a lot of artefacts (models, documents, presentations, plans, posters). We collect a lot of references and create many “working files” (such as notes, spreadsheets, outlines, templates). We share with other parties in business, I.T., vendors and advisors.

It is a daunting task to keep all of this stuff straight, to find it when we want it, to ensure that we have the right version. Difficult to make a consistent change across the various mentions of a particular thing, for example: a Business Unit has been renamed - how can we reflect that across all references in all the various models and documents?

We can of course build a library of documents, often a network drive or Sharepoint portal. This may start out well, but often quickly devolves into a large bucket. A better solution is to have electronic document management, where artefacts are stored, indexed, versioned, searchable and sharable with appropriate permissions. This can work well with appropriate discipline. It still suffers from the maintenance problem we mentioned. E.g. Updating things mentioned _inside_ models, presentations and other artefacts consistently.

This is where we need a proper repository. This may do document management too: the key difference is that a repository will manage _objects_. These can be course grained, such as the documents and models mentioned. They can also be fine grained, such as the things of interest inside the documents, models etc. A repository allows having the same object reflected in multiple models, documents, reports, matrices etc. This greatly facilitates impact analysis and maintenance to ensure consistency. It also allows integration of different domains or perspectives. For example, I can mention Business Objects (which derive from a Conceptual Data Model) in a Business Process Model, or a Requirement Specification for a Business Intelligence Dashboard.

To provide this sort of flexibility, the repository should allow customisation of meta models. I.e. we should be able to define: the concepts we are interested in, the relationships that they can have to other concepts, the properties that are important to a concept. Also, how we want to represent the information in various ways including: forms, reports, models, documents, matrices, etc. The repository solution should provides easy import from standard formats as well as APIs for easy integration to other tooling. Global search facilities and a strong security system are valuable too.

Our EVA toolset provides such a repository. The philosophy is that it's easy to capture information from a variety of sources: CSV, XML, Web Forms, Graphical Modelling; store it all semantically regardless of source; use it for analysis; and output in many forms: Query, Lists, Matrices, Visualisations, Graphical Models, etc.

Read more about EVA here.

#enterprisearchitecture #enterprisemodelling #repository #tools

All Roads Lead to ROME

No, not the historic city. And in fact not all, but few! ROME here stands for Return on Modelling Effort, a term coined by Op 't Land, Proper, Waage, Cloo and Steghuis in Enterprise Architecture - Creating Value by Informed Governance. Springer, 2008.

It is important: organisations spend thousands of hours and millions in revenue building various kinds of models in strategy, finance, enterprise architecture, requirements, solution design and other areas. Often these are useful to their creators, but do not deliver organisational value in excess of their cost.
The problems are often related to appropriateness of models to the kinds of analysis required, accessibility of the models to relevant stakeholders and quality of the models themselves.

Appropriateness relates to the relevant concepts being included, the ability of the models to capture knowledge, share knowledge, support analysis and insights and serve as inputs to further steps. It is also influenced by the appropriate level of abstraction and detail.

Accessibility is related to the representation of the models in ways that are familiar to the relevant stakeholders, ease of sharing and distribution. Architects love complex graphical models, but a business executive might prefer a poster, powerpoint deck or even a story. A financial executive will prefer a spreadsheet or graph. We also need ways to deal with complexity and scale to make them manageable, as well as ways to highlight important insights, rather than overwhelm with volume.

Quality is related to accuracy of gathered information, mapping to the model, fidelity of the modelling techniques and accurate translation to accessible output formats.

Achieving high ROME depends upon a few fundamentals, including: clearly understanding the purpose of the models; identifying and knowing the frame of reference of the Stakeholders in both business and technical domains; choosing appropriate modelling concepts, techniques and representation language that is effective, concise, efficient and precise enough. It also requires sharing outputs (including interim or evolving ones) and engaging various stakeholders positively in the process of model formulation, improvement and evolution.

#ROME #Modelling #EnterpriseArchitecture #BusinessArchitecture #ModellingLanguage

Enterprise as Social Entity

An enterprise is also a social entity, a mini-society, if you will. It has its own culture, politics, strata of status, winners and losers, factions and support groups. It has the upwardly mobile and those nearing retirement. It has immigrants finding their feet. Like a city, province/state or country, it has neighbours and others that it interacts with from afar. It has a government in the board and executive, and local government in the lines of business and departments. It has a geography (physical or logical).

This is pretty fundamental when we consider change, as we do in Business Architecture. We need to think of the greater good of the various constituencies. We have to think about our trading partners (customers, suppliers, channels).

Like other social entities, we can make plans and devise strategies, but their success will depend upon convincing independent minds to follow the plan and adhere to the rules. This requires that the plan be to the advantage of most participants, defensible in terms of logic and evidence, and achievable in terms of resources available.

We will also have to present our plans in ways that are familiar (in terms of vocabulary, format, medium, world view) to the “government” of the day, i.e. those who take the decisions to proceed, provide the resources and funding and take accountability for delivery.

From an architect’s perspective, this means we need to gather reliable data, do sound analysis, recommend good strategies, leverage all the soft skills of interaction, persuasion, reaching consensus and present our deliverables in accessible and convincing ways to the relevant stakeholders.

A lot of my recent research has been focused on the design of relevant meta models to integrate all the various dimensions in an holistic way; to build useful models that allow us to rapidly gather, analyse, design and share pertinent insights; and the design of compelling visual language(s) to convey these efficiently and effectively. Additionally, we need to support these activities in competent tools that allow rapid progress and collaboration while improving rigour and reuse.

Change is scary for people. We need to identify and ameliorate risks. We need to provide effective programme and project management, change management, mentoring and coaching. We may not be experts in all these dimensions, but we can certainly work on enhancing our soft skills and engaging those whose focus/profession it is.

Enterprise as Organism/Social Entity (4)

At Inspired we use the phrase “Desirable Futures”. When we are doing enterprise architecture, especially business architecture, we are effectively proposing a future. We contend that it should be a desirable one. Let’s define “desirable”:

• The enterprise should survive

• The enterprise should add value to all stakeholders (customers, suppliers, staff, partners, shareholders, unions, society at large)

• The enterprise should do no harm. It should not exploit any group to their disadvantage, pollute, deplete irreplaceable resources or otherwise cause harm

• Ideally:

  • It should provide utility, value, good service and delight in its products and services

  • It should be a great place to work where staff can grow and realise potential while contributing to the value delivered

  • It should be a valued and trusted partner to other enterprises

  • The enterprise should operate legally, ethically and sensitively to the norms and customs of the communities it engages with

  • It should leverage knowledge, skill, technology and industry for these purposes
    Achieving the above demands that we consider the business issues (e.g. financial health, partner relationships, products and services, growth etc.), human issues (e.g. customer journey, staff roles, organisation structure, motivation etc.) and technology opportunities holistically.