I’m reading a great new book called Intersection: How Enterprise Design Bridges the Gap Between Business, Technology, and People by Milan Guenther

The book discusses modern Enterprise Architecture perspectives like the Outside In approach and provides a holistic design lead approach that is focus more on the customer than on the underlying applications, technology and infrastructure.

The book also addresses the corporate branding of an enterprise. A successful brand is grounded in the strategic future vision of an enterprise. This strategic vision is also what drives the enterprise architecture initiatives, so it is clear that the enterprise architecture discipline must then provide the key support for understanding what contributes to the brand, what makes the brand successful and what must be done to sustain the brand.  This is a refreshing perspective that tends to get lost in most organisations.

The knowledge of messages, business events, interactions with stakeholders, outside in scenarios, business services and value streams that are defined and designed as part of the business architecture domain will all enable senior executive to understand and develop their brand. A brand is not just the value proposition, the set of products and services offered, but includes the development of the reputation of the enterprise, the customer experience it provides and the trust the customers develop. The book describes this in terms of the form, appearance, communication and behaviour of the enterprise and much more

Enterprise Architecture will have a profound impact on the brand and ultimately on the financial success of the business.

This book is a must read that should be on the bookshelf of every true Enterprise Architect.

See Enterprise Design Framework

A friend of mine Ian Glossop, is doing a survey of views on Enterprise Architecture, and as many of you are Enterprise Architects he would appreciate your views on the subject.

I know your time is precious, and the survey is a little long,  but nevertheless may I urge you to take a little time to complete it.

The survey is implemented as a PDF form, with the ability to save the data you enter and so may be completed and emailed back to:

Ian Glossop ( ian.glossop@glomal.co.uk)  at your convenience.

The form may be downloaded from here:

http://www.glomal.co.uk/EASurvey/EASurvey.pdf

Ian is doing this as part of an MSc course in Technology Management with the Open University, so he would very much appreciate your help.

The thesis that Ian is testing is twofold really:

  • That there is a common core to the diversity of EA methods/methodologies and
  • That it is a new-ish (if you can call 25 years old ‘new’) integrative discipline.

If you would like a copy of the results, simply let Ian know and he’ll send you something in September or October.

Thanks.

I’m often confronted by solution architects, IT and technical architects who don’t understand what Enterprise Architecture is all about. They usually misinterpret enterprise architecture from their own perspective as some kind of system design of ‘enterprise’ scale IS/IT systems and become frustrated when they discover that it is really something else. It often turns out that they are not usually working at the right level or with the right stakeholders in their organisation to be true enterprise architects. They are not working with the leadership team but within the scope of a small development project.

They can’t therefore see the wood (the ‘Enterprise’) for the trees (a project), let alone the helicopter view…

Enterprise architecture is in reality one of the most powerful management approaches that can be used by an organisation. It is not intended to be used (only) at a solution or project level but for the big decisions that an organisation’s leadership team have to make. The leadership (i.e. the C-level executives, and heads of divisions etc.) have to make the decisions based on the facts and knowledge base (the Enterprise Architecture repository) delivered by the enterprise architecture function. Those decisions are supported by the enterprise architecture function planning their execution in the EA roadmap. Each initiative in the EA roadmap is typically a new or changed Capability or Capability Increment (see MODAF and http://www.mod.uk/NR/rdonlyres/E43D93F6-6F43-4382-86BD-4C3B203F4AC6/0/20090217_CreatingCapabilityArchitectures_V1_0_U.pdf).

Typically the focus of Enterprise Architecture is on:

  • Increasing the return on business and IT investments by more closely aligning them with business needs.
  • Identifying areas for consolidating and reducing costs
  • Improving executive decision making
  • Increasing the benefits from innovation
  • Delivering strategic change initiatives
  • Managing business transformation activities

The Enterprise Architecture is also characterised across the following multiple dimensions:

  • Direction: Enterprise Architecture is focused on strategic planning (i.e. business transformation, strategic change programmes) and not on operational change (i.e. run the business, six sigma, lean processes)
  • Scope:  Enterprise Architecture is focused on the whole of the business (i.e. the Business Model and Business Operating Model) for all business and IS/IT functions, and not just on the IS/IT components.
  • Timeline: Enterprise Architecture is focused on the long term view of the future scenarios (up to 3/5 years in the future) and not just on a short term view of current state. Enterprise Architecture is focused on a roadmap of changes to an organisation’s capabilities.
  • Value Chain: Enterprise Architecture is focused on the whole of the enterprise (i.e. the extended organization and value chain) and not just on the scope of a delivery project
  • Stakeholders: Enterprise Architecture is focused on the needs and concerns of the C-level executives (CEO, CIO, COO etc.), business executives, corporate and business strategists, investors, strategic planners.

(ps. I tried to draw a diagram to illustrate where Enterprise Architecture lies on these dimensions but couldn’t visualise a multi-dimensional space…)

So overall, the primary purpose of Enterprise Architecture is to support strategic change such as :

  • The introduction of new customer and supplier channels such as  eCommerce
  • The consolidation of the existing portfolio of people, processes, application and infrastructure etc.
  • The reduction of costs and risks, ensuring the enterprise will remain viable and profitable
  • The design of a new organisation, business model and business operating model.
  • The due diligence for mergers and acquisitions and management of the resulting integration programme.
  • The development of smarter and more effective systems (not just IT systems).
  • The introduction of shared services and applications.
  • The introduction of new technology, platforms and infrastructure such as SaaS, Cloud etc.
  • The introduction of regulatory and legal changes such as Basel 3

 

In my future blog entries I will explore how Enterprise Architecture supports some of these areas.

The first one will be about how Enterprise Architecture is used to support Due Diligence activities prior to mergers and acquisitions.

 

How does an Enterprise Architecture and a Business Model work together?

Successful organisations are those that improve and innovate their Business Models to find a profitable niche against their competitors.

But a new Business Model alone is not enough. It needs to be implemented and executed. This is where an Enterprise Architecture comes in.

If organisations do not align their Business Model and their Enterprise Architecture then how can they be certain of making it work?

The first step is integrating the Business Model with the Business Architecture part of the Enterprise Architecture. This is described below.

Business Model Canvas

Business Model innovation is rapidly becoming a hot topic and especially with the release of the book ‘Business Model Generation’ by Dr Alexander Oesterwalder. http://www.businessmodelgeneration.com/

This book introduces a standard way of developing a Business Model called the Business Model Canvas. If you are an Enterprise Architect highly recommend you read it.

Up to now most organisations had their own informal and idiosyncratic way of defining a business model that was unique just to themselves. This is the first time a standard for developing a business model has been defined and published.

Business Model Canvas

The Business Model Canvas is a powerful approach for business model design and innovation.

It captures the 9 most essential elements of a business model in a simple way, enabling the design of a ‘business model on a page’.

The 9 different segments are

  • Customer Segments
  • Customer Relationships
  • Channels
  • Value Proposition
  • Key Activities
  • Key Resources
  • Key Partners
  • Cost Structures
  • Revenue Streams

You can see some example Business Models developed with the business Model Canvas at http://www.businessmodelalchemist.com/ and on an associate web site where you can view a variety of example Business Models and try creating your own can be found at http://bmdesigner.com/ .

So what does all this have to do with Enterprise Architecture?

Enterprise Architecture exists to provide a path between strategy and execution, identifying the current state and the desired future state and plot a roadmap of strategic changes between them.

See book ‘Enterprise Architecture as Strategy’ –  http://www.architectureasstrategy.com/book/eas/

Enterprise Architecture provides the organising logic and architectural thinking needed to design the appropriate business capabilities need to implement a Business Model. To get the right outcomes, organisations must focus on Enterprise Architecture and Business Architecture not try and jump straight to IT architecture and solution design.

After setting the overall mission and enterprise vision, the first Enterprise Architecture domain that we need to model and align with the Business Model is the Business Architecture.

Business Architecture Model

A Business Architecture model is used further elaborates the 9 high level concepts segments that have been populated with conceptual themes and business strategies in the Business Model Canvas. A number of techniques and approaches, views and artifacts are used to explore the themes and strategies in each Business model canvas segment.

Customer Segments

Create a Porter’s Five Forces model to explore the market and the general business environment in which the organisation exists. Also conduct a SWOT analysis.

Create a VPECT model to explore the Values, Policies, Events, Content (outcomes) and Trust relationships from the perspective of each different customer segment.

For details of VPECT read the book ‘Lost in Translaton’ by Nigel Green and Carl bate – http://www.lithandbook.com/

Customer Relationships

Create a Business Event model, further elaborating the Business Events identified with the VPECT model.

For each current and especially the future Events, create a Business Scenario. This should explore he what if questions that will effect the business model in the future.

Channels

Create a model of the various channels that exist between the organisation and its customer segments as well as between the organisation and its partners and suppliers.

Don’t forget those new social media channels, such as iPhone or Android phones and other devices and applications such as Twitter and Facebook. Partners can also be channels as well.

Create a model of the flow of business information between the organisation and its customers and between the organisation and its partners and suppliers (use the Actor Co-operation Viewpoint in Archimate).

Value Proposition

Use VPECT to explore what Value you provide to each customer segment and what problems you solve for them.

Create a Value Proposition Model of the Products, Business Services and associated Values (using the Product Viewpoint in Archimate).

Value Propositions drive Business Strategy, so create a Business Motivation Model to understand all the relationships between Vision, Goals, Objectives, Strategies and Tactics associated with the Value Proposition.

See http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf for details of the Business Rules Group’s Business Motivation Model.

Key Activities

Key activities includes any model of behaviour,

This should include both internal Business (organisational) Services, Business Functions, Business Processes and Activities as well as the external behaviour of your customers, partners and suppliers.

In some cases it is useful to think about behaviour in terms of external services (the what) and the internal behaviour (the how).

Create a Business Function Model (using the Business Function Viewpoint in ArchiMate). A useful approach to use here is the Component Business Model approach from IBM. See http://www-935.ibm.com/services/uk/igs/html/cbm-bizmodel.html

IBM’s Component Business Model provides a good basis for visualising the Target Operating Model in terms of Business Functions or in terms of Business Capabilities (they’re not the same thing…).

Create a Business Process Model (using the Business Process Viewpoint in ArchiMate). Business Process Models are not just Process Hierarchy Models but include Value Chains and Value Streams.

Create Value Stream models for each Event/Outcome pair (use the Business Process Viewpoint in Archimate) identified in the customer relationship segment above.

Create a Value Chain model at a high level for each customer segment (also using the Business Process Viewpoint in Archimate).

See http://www.opengroup.org/archimate/doc/ts_archimate/ for details of modelling the Business Architecture Layer in Archimate.

As they are high level abstract views, Value Chains are often specified more in terms of Business Functions than the more specific Business processes or Activities.

Key Resources

Resources in this segment can be further elaborated by the other Enterprise Architecture domains or Information Architecture, Application Architecture (and Application Service Architecture) and Infrastructure Architecture.

However before jumping to the IT Architecture it is better to start more conceptually and create an Enterprise Vision Model and a Business Capability model.

Enterprise Vision models are those high level one page models described as ‘core’ models in the book ‘Enterprise Architecture as Strategy’ (http://www.architectureasstrategy.com/book/eas/) and also in TOGAF Phase A.

You can also use the Layered Viewpoint in ArchiMate to produce Enterprise Vision Models.

Create a Business Capability model. This is usually a hierarchy model similar to a Business Function Model but remember that a Business Function and a Business Capability are two different concepts.

A Business Function is a high level view of existing internal behaviour from an organisational perspective, where the business functions are closely associated with the organisation units.

A Business Capability is defined by TOGAF9 as ‘A business-focused outcome that is delivered by the completion of one or more work packages’. A Business Capability is defined as the ability to execute a specified course of action, to achieve specific strategic goals and objectives. A Capability is defined in terms of the outcome of the course of action, one that has a business value. The concept of Capability is used in the military context and the MODAF framework where it is described in the abstract. See http://en.wikipedia.org/wiki/Capability_management and http://tinyurl.com/2vge39e

See also my previous post on Modelling Behaviour.

Create an Organisation model (using the Organisation Viewpoint in ArchiMate) to capture the human resources and their roles and responsibilities.

Create a Business Information Model (using the Information Structure Viewpoint in ArchiMate) to understand the knowledge, information and data resources within the organisation. Outcomes identified as Content in the VPECT model and in the Value Stream models are also modelled here as Business Information (represented by Business Object, Meaning and Representation object types in ArchiMate).

Key Partners

Identify your key partners, suppliers as carefully as you do your customer segments and customer relationships.

Don’t forget that Enterprise Architecture includes the extended environment as well as the organisation itself. This extended environment includes the Suppliers and Partners (use the Actor Co-operation Viewpoint in Archimate).

Cost Structures

Explore the costs with a Total Cost of Ownership (TCO) model.  This can be a spreadsheet.

Create a System Dynamics Models to fully explore and understand the cause and effect relationships between different stocks and flows, and run simulations.

See http://en.wikipedia.org/wiki/System_dynamics

Revenue Streams

Also explore revenues with a TCO model as with the Cost Structures

Remember that revenue doesn’t always mean profits in terms of money, but can be other non-monetary outcomes of value, (especially relevant for Government departments, non-profit and charity organisations who seek outcomes in terms of benefits to citizens and indirectly, votes).

It is again very useful to produce System Dynamics Models to understand the cause and effect relationships between different stocks and flows.

I think it’s surprising that more organisations don’t use System Dynamics as part of their enterprise architecture modelling. More on that subject in a future post…

Other Enterprise Architecture models

Starting from the Business Model Canvas, the Business Architecture views described above are used to further elaborate the details of the business model and to understand what needs to be realised from a business perspective.

After that the Business Architecture model is aligned to the Information/Data Architecture model, the Application Architecture model and finally the Infrastructure Architecture model pretty much as usual.  I mostly develop these models using Archimate combined with other concepts from TOGAF 9 as needed, using tool such as Avolution Abacus and BiZZdesign Architect.

Note that other variations of Oesterwalder’s Business Model Canvas are starting to emerge. This is a sure sign that the concept is an important one that is reaching a tipping point.

These other business model approaches include:

Modelling Behaviour

19 October 2010

I frequently find that there is much confusion about the modelling of Behaviour in an Enterprise Architecture model, specifically between the concepts of Business Capability, Business Function and Business Process. The various enterprise architecture glossaries all differ in their definition of these.

For example the TOGAF ADM or ISEB definitions don’t help as much as they could.

TOGAF quite reasonably defines Capability as ‘A business-focused outcome that is delivered by the completion of one or more work packages. Using a capability-based planning approach, change activities can be sequenced and grouped in order to provide continuous and incremental business value’.

However elsewhere TOGAF says that ‘The term “function” is used to describe a unit of Business Capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc.’. This confuses Business Capability with a Business Function.

ISEB says that a Business Function is ‘An idealised or logical subdivision an enterprise’s capability.’ and also that a Business Capability is ‘A business function whose performance is the subject of management attention … It is usually a high level and cross-organisational business function.’ Other methods I have encountered confuse Business Functions with Activities and have Business Processes decomposing into Business Functions.

ArchiMate has the most clarity about Business Functions and Business Processes but doesn’t as yet define a Business Capability.

One of the first artifacts to be produced as part of a Business Architecture model is a Target Operating Model. This is where definition issues are often first seen.

A Target Operating Model is usually a view of the organisation structure showing the Business Functions that each organisation unit is responsible for, but often these are also rather casually referred to as Capabilities.

Even more casually, it’s not uncommon to find the Target Operating Model actually contains a mixture of Business Processes, Business Functions and Business Capabilities with some Business Services thrown in for good measure.

It’s time for a bit more preciseness, less fuzziness and better standard definitions. ArchiMate has helped enormously by providing a standard enterprise architecture language but it still allows some fuzziness.  See http://www.opengroup.org/archimate/doc/ts_archimate/

Below I’ve described the definitions I encourage the use of.

Behaviour concepts

Business Capability

A Business Capability is defined as the ability to execute a specified course of action, to achieve specific strategic goals and objectives. A Capability is defined in terms of the outcome of the course of action, one that has a business value. The concept of Capability is used in the military context and the MODAF framework where it is described in the abstract. See http://en.wikipedia.org/wiki/Capability_management and http://tinyurl.com/2vge39e

A Business Capability is not a Business Function, but is a concept that encapsulates other objects, in particular Actors (organisation units), Roles, Policies, Standards, Skills, Business Functions, Business Processes, Products, Business Services, Application Services, Application Components and Infrastructure. A Business Capability is therefore used for managing units of strategic business change.

A military example of a capability might be ‘2000 air freight sorties’, ‘1 Tonne heavy lifting’ or ‘Personnel Recovery under fire’ (but not ‘Helicopter’ or ‘Flight Management’). A business example might be ‘eBusiness’ (or the ability to sell new or existing products and business services to customers via the internet).

Business Capabilities can be decomposed into component business capabilities creating a capability hierarchy. A Business Capability is named after the desired outcome.

Business Function

Business Function is an organisational perspective on behaviour. It is not the same as a Business Capability. A Business Function defines the ‘what’ behaviour that is associated with an organisational unit and modelled in a target operating model. In many ways the Business Function is equivalent to all the behaviour that is modelled in an organisational specific swim lane in a Business Process Flow view (i.e. a BPMN diagram). A Business Function is typically named with a suffix of ‘management’ (i.e. ‘Customer Relationship Management’), but could also be a single noun (i.e. ‘Billing’).  Business Functions can be decomposed into component business functions, resulting in a business function hierarchy. A Business Function does not decompose into a Business Process or an Activity.

A useful example of a Business Function model is IBM’s Component Business Model, where the ‘components’ are (usually) Business Functions. See http://www-935.ibm.com/services/us/imc/pdf/g510-6163-component-business-models.pdf

Business Process

A Business Process is another perspective on behaviour and defines the behaviour from the ‘How’ (how work is done) perspective. It represents both a complete Business Process Flow and the elements in a Business Process Flow. A Business Process Flow view (i.e. a BPMN diagram) is a view that shows a sequence of sub-Business Processes or Activities that are triggered by  a Business Event. See http://en.wikipedia.org/wiki/BPMN

The sequence of Business Processes can represent a Value Chain at a macro level or the detail elements in a Value Stream that is triggered by a Business Event and results in an outcome of value to the source of the Business Event, usually a customer. See http://en.wikipedia.org/wiki/Value_chain and  http://en.wikipedia.org/wiki/Value_stream_mapping

A Value Stream is a more detailed version of a Business Scenario (TOGAF).  Business Processes are named with a Verb + Noun phrase.

A Business Processes representing a Value Stream is named after the Trigger + Outcome i.e. ‘Order to Cash’ or ‘Prospect to Customer’

The Enterprise Business Architecture book is highly recommended as a source of examples of a Business Process Model with Business Processes representing Value Streams.  See http://www.enterprisebusinessarchitecture.com/

High level Business processes are typically aggregations of more specific Business Processes (sub-processes) or Activities.

Business Processes can be decomposed into component business processes, i.e. into a business process hierarchy. At the lowest level of sensible decomposition (i.e. at one place, at one time, by one person or system) the elementary business process is usually called an Activity. Activities are what are modelled in a BPMN diagram and are realised by a person (providing an organisation service) or by an application service or application. An Activity doesn’t decompose into a Business Process or into a Business Function.

A macro level Business Process (i.e. representing a Value Chain, or a column in a Component Business Model) may be used to group a number of Business Functions. Note that there is a many to many relationship between Business Functions and Business Processes. One Business Function may group many Business Processes and one Business Process may be used by many Business Functions.

An example of this can be seen in the eTOM (Enhanced Telecom Operations Map) where Business Functions and Business Processes are orthogonal to each other.  See http://en.wikipedia.org/wiki/ETOM

Business Service

A Business Service represents an external view of the services an organisation provides or sells to its customers alongside the sale of a Product. A Business Service may be realised by a Business Function or directly by an Application Service, but is more usually modelled as being realised by a Business Process.

Business Services can be decomposed into component business services i.e. into a business service hierarchy. I’ve also found it useful occasionally to create a Business Service Flow view, which is similar to a Business Process Flow view but seen from an external customer’s perspective instead of the internal ‘How’ perspective of a Business Process Flow view.

Clarification of all these Behaviour concepts is an important step towards improving and evolving a common understanding of the business architecture layer within all enterprise architecture models.

I was recently asked about the adoption trend of ArchiMate.
I see demand for ArchiMate support slowly increasing in the UK, but it is nowhere near the tipping point that it has already reached in the Benelux area, especially in the Netherlands of course, where a requirement for enterprise architects to have Archimate experience is ubiquitous.
I’ve come across many Enterprise Architects and Solution Architects that are aware of Archimate and have been using it in their models, even if the organisation as a whole has not yet made it a standard.
From discussions I’ve had recently I understand that interest in the USA and in South Africa in ArchiMate may be growing faster at the moment than in the UK.
The main motivation for the ArchiMate foundation transferring their intellectual property to the Open Group was to to enable ArchiMate to reach a global audience.
At the time that Archimate was first developed, TOGAF didn’t have a meta model so there was a significant need for one to complement the ADM.
ArchiMate is the only defacto standard modelling language for enterprise architecture in the same way that BPMN and UML are defacto modelling languages for BPM and solution design respectively. I’d like to see the Open Group doing much more to promote ArchiMate now that it is in their stable alongside TOGAF 9.
However I foresee that in the next version of TOGAF meta model and ArchiMate meta model will merge. The TOGAF 9 meta model has many good features and a wider scope but is not quite as mature or complete as the older more tested ArchiMate meta model. I discuss some of my ideas about this on my wiki site and plan to produce a paper on the subject shortly.
The TOGAF ADM and ArchiMate complement each other and can be used well in combination.
What I have found is that the ArchiMate meta model resonates very well with clients that want a simple to understand set of Enterprise Architecture concepts that supports their way of thinking and also supports a service oriented architecture approach. Archimate maps easily to BPMN and UML modelling by design, so it is useful for translating Enterprise Architecture models into more detailed solution architecture models.
A large number of EA tools already support ArchiMate. These include:
  • BiZZdesign Architect
  • Avolution Abacus
  • Sparxsystems Enterprise Architect
  • IDS Scheer Aris,
  • Casewise
  • System Architect
  • Salamander MOOD
  • Archi
ArchiMate can also be used with the Troux EA repository, which can be configured to support it, and as I’ve mentioned I’ve already customised Mega for two clients to enable better support for ArchiMate.
If you want to know more about ArchiMate then I have a created a 2 day course to introduce the concepts and use of ArchiMate.
Contact me at adrian.campbell@enterprisearchitects.com for details.
http://tinyurl.com/2wg28kp

I have recently finished reading the book ‘Lost on Translation’ by Nigel Green and Carl Bate and found it a very useful and insightful. I recommend it for the shelf of any Enterprise Architect. See http://www.lithandbook.com/

The book describes the VPEC-T ‘thinking framework’ and a focus on understanding the Values, Policies, Events, Content and Trust perspectives and provides a useful language to use when speaking with the business about any strategic change.

Being keen advocate of using Archimate (http://tinyurl.com/cf3z25) for developing Enterprise Architecture models, it struck me the next step after a VPEC-T based conversation would be to write up the outcomes in an Archimate model.

So what is there in Archimate that would be useful?

The first thing I noticed is that more or less all of the Business Layer meta model concepts in ArchiMate are in scope for VPEC-T and the Application Layer and Technology Layer are not.

ArchiMate Business Layer Meta Model

That’s not to say that VPEC-T wouldn’t be useful for the application and technology layers, but it seems to be naturally focused on the Business Architecture side of things to me at the moment.

So how does VPEC-T map to ArchiMate concepts?

V = Values

The obvious first Archimate concept to use here is ‘Value‘.

ArchiMate users don’t use Value as much as they should in their models in my opinion. Using VPEC-T will correct that.

ArchiMate defines Value as that which makes some party (represented by Business Actor, Business Role) appreciate a Business Product and/or associated Business Services that they are buying, using or acquiring.

Value in this sense is also associated with a value chain (which is modelled in terms of a sequence of Business Processes and Business Activities that provide a Value).

I would also use the ArchiMate concept of Meaning.

Archimate defines Meaning as knowledge or expertise present in the representation of a Business Object, given a particular context. I would use Meaning to represent the inherent shared knowledge or value system that users have as their mental model.

P = Policies

There is no ArchiMate concept for Policy as such in the 1.0 specification but a number of EA tools that support ArchiMate do support it.

I would generally use the ArchiMate concepts of Business Function, Business Process to represent aspects of Policy. These should be used with care though, such as more in the sense of Business Rules, Guidelines, Policies, than with the normal meanings of Business Function and Business Process.

I would also use the ArchiMate concept Business Object, to represent Strategies, Goals, Objectives, Business Decisions,

In the conversation about Policies would be a focus on the Target Business [Operating] Model, in terms of what Business Product and Business Services would be sold or provided to what customer segments, i.e. Business Roles. This overlaps a bit with how one would represent a Business Model in ArchiMate which will be the subject of a future blog entry.

E = Events

The obvious Archimate concept to use here is a Business Event.

This is a key concept, and it seems especially obvious to use it in a message and service driven architectures, but it’s curious how infrequently it is actually used in most of the BPMN style models I have seen people develop.

I first started modelling with Events using IDS Scheer’s ARIS tool in 1998 and the power of an event driven approach has stayed with me ever since.

Business Events are used to trigger a value chain that results in an outcome that has Value.

Value chains are modelled using s sequence of Business Process and Business Activity and outcome of a value chain is represented with a Business Object, Business Product, Business Service associated with a Value.

Since Business Events occur via various channels, it might also be useful use the ArchiMate concept of Business Interface (representing a Channel) in your VPEC-T model, but that is a bit like solution design so is optional.

C = Content

Archimate can be used to model Content at several different levels of knowledge, information and data.

The Meaning object is used to represent knowledge, the Business Object for business information, the Data Object for data, the Representation object for the physical representation of information and the Artifact object for the physical storage of data.

In a VPEC-T model created with ArchiMate, I would mainly use the Meaning, Representation and Business Object concepts.

T= Trust

To me Trust is all about relationships, interactions and collaborations between people.

I would use the ArchiMate concept of Business Actor, representing an organisation, organisation unit or a person, and the concept of Business Role, representing the roles played by those organisations, organisation units or persons in relation to others.

For the trust relationships I would use the ArchiMate concept of Business Collaboration and Business Interaction. These don’t get used in many Archimate models but I think they are useful for representing aspects of Trust relationships.

A Business Collaboration is defined in ArchiMate as a (temporary) configuration of two or more business roles resulting in specific collective behaviour in a particular context.

A Business Interaction is defined as a unit of behaviour performed as a collaboration of two or more business roles.

I would also use the Archimate concept Contract to represent a Trust agreement (such as a Service Level Agreement) between parties.

ArchiMate concepts for VPEC-T models

Overall for doing Enterprise Architecture, I recommend using a ‘thinking framework’ such as VPEC-T first and then an Enterprise Architecture framework and modelling language such as ArchiMate second.

Recently I’ve tried the latest versions of the following EA tools:

  • BiZZdesign Architect
  • Avolution Abacus
  • Salamander MOOD
  • Mega
  • MetaStorm ProVision

The first two are definitely modern tools that fully support IEEE 1471 concepts and separation of concerns. Easy to use and good for Enterprise Architecture modelling without fuss.

Both are excellent.  MOOD is fine and attractive, but I’ve used it less in anger.

The last two suffer from an odd design quirk that means that a view (i.e. a diagram) must belong to an object.

The result of this quirk is that to create context free diagrams they must belong to a dummy object. Why are these tools built this way ?

Another common feature is a proprietary way of drawing business process flow (Workflow / Event value chain) diagrams in a truly BPMN style.

The data object that is input or output from a Business Process or an Activity is not the same data object that is modelled elsewhere in the tool. Mega is particularly bad at this.

Neither Mega or ProVision seem to know how Services (Business Services, Application Services etc.) should be modelled either.

A colleague also pointed out to me that many EA tools are pretty limited when it comes to modelling the Infrastructure Architecture at an Enterprise Architecture level. Both Mega and ProVision are the most limited in this domain.

Both Mega and ProVision can be customised to improve them for EA use, but I for one would expect support for modelling SOA and the infrastructure to be there by default. I’d also expect to see support for the de facto EA modelling language ArchiMate to be there by default.

In comparison both Avolution Abacus and BiZZdesign Architect are sweet and painless to use and do everything you want them to do.

So why are they not in Gartner’s Magic Quadrant for EA tools then?

Recently I was asked about the concepts of a Business Function and a Capability, and how it is unfortunate that these concepts tend to be blended together. 

a) How do you differentiate between these concepts?

b) Is there a value to modeling both, or do you find that organizations that use one tend not to use the other?


My answer is copied below.

I have also often found that people confuse Function and Capability. They are certainly different in my opinion. 

Many enterprise architecture efforts don’t really focus much on either of these concepts and instead just focus on modelling business processes, applications and infrastructure. 

 

This is because the Organisation Architecture and Strategic Planning domains are not included with the scope of Enterprise Architecture within their organisations.

However since ArchiMate includes the concept of a Business Function and now TOGAF9 (Capability-Based Planning  -  http://www.opengroup.org/architecture/togaf9-doc/arch/chap32.html) includes the concept of a Capability so I’d expect more Enterprise Architects to start using both these concepts more than they have previously.

 

A Business Function is a concept used in the Organisation Architecture domain and represents what work is done by that organisation, organisation unit or business role.  An organisation can be designed as a set of Business Functions and usually the structure of the organisation units within an organisation is closely based on the business functions.

Those Business Functions are more stable than the organisation structure itself and often an Organisation Unit or Business Role may be responsible for multiple business functions.  A Business Function is only ever carried out by a single Business Role/Organisation Unit within an organisation.

Examples of Business Functions include: Sales, Mаrketing, Supply Chаin Management, Finаnciаl Mаnаgement, Operations, Customer Relationship Management, Product Management, Supplier/Pаrtner Relаtionship Mаnаgement.

A Capability is a description of an ability to do something in terms of expertise and capacity. 

It is associated with strategic planning and not the Organisation Architecture or Business Architecture domains. A Capability is delivered through the establishment of a number of different changes usually at together as a group of changes delivered in an iteration. 

These changes are likely to include new or changed organisation units, business functions, business processes, business services, application services, application components, infrastructure services, infrastructure components (Nodes etc), business objects, data objects etc.

A Capability is used as the unit of change in strategic portfolios and Capability Increments (TOGAF9) are used in programme and project portfolios. 

Examples of Capabilities include: Capability to sell a new Product, Capability for eCommerce, Capability for rapid merger and acquisition activities, Capability to survive the credit crunch, Capability to conduct research, Capability to achieve delivery objectives and be ready for future unknown challenges.

 

References:

ArchiMate (http://www.archimate.org/ART/) defines a Business Function as:

A business function is a unit of internal behaviour that groups behaviour according to for instance required skills, knowledge, resources, etc., and is performed by a single role within the organisation.

A business function describes internal behaviour performed by a business role that is required to produce a set of  products and services.  For a consumer the products and services are relevant and the required behaviour is merely a black box, hence the designation: internal.

There is a potential many-to-many relation between business processes and business functions. 

Informally speaking, processes describe some kind of ”flow” of activities whereas functions group activities according to required skills, knowledge, resources etc. 

Complex processes in general involve activities that offer various functions. In this sense a business process forms a string of business functions.

In general, a business function delivers added value from a business point of view. Organisational units or applications may coincide with business functions due to their specific grouping of business activities.

TOGAF9 defines a Function as:

Function describes units of business capability at all levels of granularity.

The term “function” is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc. 

Any bounded unit of business function should be described as a function.

[a Function] Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by the organization. Also referred to as “business function”.

TOGAF9 defines a Capability as: 

A business-focused outcome that is delivered by the completion of one or more work packages. 

Using a capability-based planning approach, change activities can be sequenced and grouped in order to provide continuous and incremental business value.

(Unfortunately in the TOGAF9 meta model at http://tinyurl.com/czrmpj, Capability is shown on its own as an unrelated concept, so I think that there is more work to be done on the TOGAF9 meta model.)

Civil Service Capability Reviews at http://tinyurl.com/cuyta9 has an interesting model of Capability.

CBDI_SAE defines a Business Capability as: The power or ability to perform something of value to your business.

MODAF defines a Capability at: http://tinyurl.com/c5lhaq

MODAF defines a Function at: http://tinyurl.com/cvkkua

Business Motivation Model:  In the Business Motivation Model the concept of a Desired_Result is closest to that of a Capability and illustrates that we should measure Capabilities in terms of Goals and Objectives and their measures.

Today I came across the Essential project -  http://protege.cim3.net/cgi-bin/wiki.pl?EssentialProject

This is a very interesting open source Enterprise Architecture project that builds on the excellent Protege Ontology Editor.

If you haven’t looked at Protege yet then go to http://protege.stanford.edu/  to find out more about this free open source ontology and knowledge tool and download a copy to try out. It has lots of uses

I also recommend going to the Essential project web site http://www.enterprise-architecture.org/ and downloading a copy of Essential to try.

Architecture of Essential

Architecture of Essential

The Essential Modeller uses Protege as it’s editor to enter the Enterprise Architecture model content, based on a Meta model pre-built in Protege.

Essential Architecture Manager
Essential Architecture Manager

 and the Essential Viewer uses a Java web application running in Apache to view the resulting Model.

Essential Viewer

Essential Viewer

The Essential Meta model is a fairly minimal EA Meta model, hence the name ‘Essential’ but it is certainly sufficient for most EA work. Using Protege it would be possible to modify the Meta Model to extend it to support other EA Meta models such as TOGAF 9  or Archimate.

On the Protege web site you’ll also find a number of interesting existing projects, including a model of the Federal Enterprise Architecture (FEA)  in OWL.

I also remember reading about a Zachman Framework being modelled in Protege a few years ago that I think used a similar approach to the Essential project to publish its contents. http://apps.adcom.uci.edu/EnterpriseArch/Protege/index.html

Also http://apps.adcom.uci.edu/EnterpriseArch/Protege/TRCEAPractice/Website/main.htm

Enjoy.

Enterprise Architecture does by definition include Business Architecture. Any other view is now rather out of date. 

Enterprise Architecture should include several domains: 

  •  Strategy 
  • Business Architecture 
  • Information/Data Architecture 
  • Application Architecture 
  • Infrastructure Architecture

In addition there are other sub-domains for Process Improvement, Governance, Audit, Security etc. 

All EA frameworks including Zachman, Archimate, IAF and TOGAF 9 recognise these distinct domains in some form. 

TOGAF 9 is increasing mature and the image at http://tinyurl.com/btxqga 
is a good baseline for understanding the various domains. 

Of course over the history of the maturing of the Enterprise Architecture discipline, it was nearly always the case that Architects came out of the IT function.

IT trained staff are more likely to be good modellers and think in rational formal ways necessary to produce good Architecture models.

Business staff on the other hand like to own their business models and have been less precise and formal about how they modelled what they do.

This is improving of late with BPMN and BMM models becoming more acceptable for business focused staff to use.

The Enterprise Architect is also increasingly becoming a Strategy & Architecture discipline and an Enterprise Architecture (as opposed to a Solution Architect) likely not to have an IT background. Many are from a Business Analysis, Programme Management, Portfolio Management background.

The ideal EA team today will have a mixture of all kinds off staff from different disciplines and will not report to the IT function.

EA is a corporate level function and not just a Business or IT function.

I have been evangelising about Archimate for a few years now in the UK and elsewhere.

Following a recent discussion, I wondered whether anyone else in the UK has also been using Archimate within their organisations and would like to get together to share their experiences, models, use of EA tools (such as BiZZdesign Architect or Avolution Abacus)?

Avolution Abacus

1 August 2008

I have recently come across the Avolution Abacus EA tool at the recent IRM UK EA Conference.

Avolution Abacus is a highly flexible tool for enterprise architecture modelling and for analysing the resulting models using pre-defined metrics.
The main features of Abacus that gives it a competitive advantage includes:

A meta-meta-model that is customisable at any time, including adding or changing component types, attributes and relationship types.
I like this feature since I invariably want to add concepts and new relationships. Some older EA tools have fixed meta models that prevent this or make it very awkward to change.

Powerful import and export to Microsoft Excel, Visio, PowerPoint and Word
I find this is also an excellent feature, especially since most organisations that I have supported in their  Enterprise Architecture efforts nealy always start out doing their modelling using office applications.

Customisable charts and graphs
I think that the charting and visualisation features are also very useful for presenting important information to senior executives, who just want to see the numbers and not the models..

Evaluation tools
There are five pre-built evaluation tools that are excellent for analysing the enterprise architecture models in terms of Performance, Total cost of ownership, Modularity, Openness and Reliability.

* The Performance simulator uses discrete event simulation to calculate the theoretical load and response of your architecture. There are a series of outputs from this simulator, the most obvious of which are the Bandwidth and Response Time properties.
* The Modularity evaluator calculates the number of incoming and outgoing connections for each component.
* The Total cost of ownership evaluator calculates the Total Cost of Ownership (TCO) for the architecture.
* The Reliability evaluator calculates the mean time between failure of the system and availability of the system given the structure of the components and connections and their properties.
* The Openness evaluator determines the degree to which an architecture and its elements are ‘open’, that is, the ability of the system to handle replacement of components with minimal impact.

Implementation Libraries with pre-defined metrics
This is an excellent feature that I have not found in other EA tools. The Implementations contain pre-defined data about existing COTS applications, infrastructure and connections that are used by the evaluation tools. This is invaluable for costing a particular future state architecture option.  Collecting this kind of data is frequently never done by organisations, and estimating costs can be largely guesswork.

Abacus supports numerous Enterprise Architecture meta models and notations as libraries.

These include:

I’d like to see the Business Motivation Model (BMM) also supported, and I’ll probably have a go creating it myself when I have a spare moment.

A demo can be downloaded at the Avolution Abacus Web Site

Today I returned to the Sparx Systems web site to see what was new and was pleased to discover that the Enterprise Architect tool can now be extended with a new MDG technology add on for the TOGAF 8 Architecture Development Method, in addition to the previous add on that was available for the Zachman Framework.

The Enterprise Architect tool is already a great tool and this add on is sure to be popular. TOGAF is increasingly mentioned as a desirable skill in job specifications for Enterprise Architects.

http://www.sparxsystems.com/products/mdg/tech/togaf/index.html

Of course, now that the Open Group has adopted the Archimate  Enterprise Architecture modelling language standard, the next add on I’d like to see is one for Archimate.

Archimate and TOGAF

30 January 2008

For a long time now I have been recommending that organisations use the TOGAF ADM as the basis for their Enterprise Architecture Development Process and best practices, and to also use Archimate as the basis for their Enterprise Architecture Framework and the metamodel of architecture elements that need to be developed.

Archimate presents a unified way of modelling enterprise architectures, integrating the architecture domains for Business Architecture, Information Architecture, Application Architecture and Infrastructure Architecture in a way that makes the models easy for decision makers to understand and read. Archimate also includes a big focus on Services within the various architecture domains, which supports the adoption of Service Oriented Architecture approach. See http://www.archimate.org/content/afbeeldingen/concepts.gif and http://www.archimate.org/content/afbeeldingen/archimate_example.gif.

I recommend the Archimate book. See http://tinyurl.com/69gx72

Anyway, the reason that I’m prompted to mention Archimate again is that good news today is that the Open Group has announced their intention to adopt ArchiMate as an independent standard for enterprise architecture modelling and analysis.

See http://tinyurl.com/5es67c

The combined use of TOGAF and Archimate is one step towards increasing the maturity of the EA discipline.

I predict that the next step in this EA maturity story will be the alignment of COBIT with Archimate and TOGAF.

There is a paper available to COBIT members that looks at the mapping from COBIT to TOGAF.

You know it makes sense!

In his recent blog at http://4thresource.evernden.net/  Roger Evernden asks ‘would you change the Zachman Framework?’.

Recently Zachman and Locke have been doing great stuff to update the Zachman Framework themselves and it always sounds great at conferences, but it isn’t enough I think.

Their problem is that is it has been a good earner for them and since it is now their brand they can not be seen to change it too dramatically.

My general thinking is that an EA framework is multi dimensional (perhaps at least the 8 dimensions introduced in the book ‘ Information First’) and that the Zachman Framework presents one of many views that are useful.

I think the main issue is that many people find the language of ZF doesn’t match the names they use for deliverables in their own environment.

Also ZF is seen as too theoretical and formal, which puts many people off.

Many are looking for a quick win, keeping it simple, just good enough, just in time. However in real life the devil is in the detail and a more complex solution is needed.

The Zachman Framework talks about primitives and composites. The primitive information is what is classified in the Zachman cells. However most people produce complex composite deliverables as long documents whcih relate more to what Zachman calls the composites.

What needs to be changed I think is to add an orthogonal view of the Zachman Framework that just shows the composites. A mapping between composites and the deliverables promoted by Prince 2, OGC and other project management processes would be a good start.

I’ll post some of my other thoughts on the Zachman Framework later on.

An Enterprise Architecture Framework need to be very accessible.
I have found that find the original Zachman Framework matrix can be too complicated for some people.
In most cases I find that people accept the columns based on the six questions, who, what , where, how, when and why.
The column names are not always understood.
There is confusion about all the rows and in which cell to put the ings such as User Interfaces, Use Cases, Objects, Classes, Components and Services.
The original Zachman Framework betrays its Information Engineering legacy and needs updating.

Does a class belong in the Data or Function Column ?
Where does a Service belong ?

If we distinguish between an organisational service (performed by people) , an application service (performed by a software application) and an infrastructure service (performed by the hardware and infrastructure platform), then should we put each of these services into a different column ?

How do we map strategy aspects and the architecture discipline ?

In response to this I have created a matrix with two dimensions:

  • Levels of Abstraction {Strategy, Architecture, System and Operations}
  • Architectural Perspectives {Information Architecture, Process Architecture, Application Architecture, Technology Architecture, Organisation Architecture and Performance Architecture}

I have found this to be more aligned with organisation view points and common terminology.

 

Follow

Get every new post delivered to your Inbox.

Join 699 other followers

%d bloggers like this: