EA supporting rapid coporate decision making

What does agile mean?

Mostly the interpretation is that it means doing the work in an iterative and incremental fashion, so that each new iteration can be flexible enough to rapidly react to constant change.

This is a good approach that should be taken regardless of whether one is doing enterprise architecture or solution development.

Other interpretations is that agile means development without architecture or analysis, where the design only meets the current set of known requirements and the solution being developed must be refactored when the requirements change.

This is good for development but not so good for long term strategic planning of enterprise architecture.

Terry Blevins has made some important insights in at the Briefings Direct blog

Enterprise Architecture exists to support the decisions that are made every day in an organisation.
Enterprise Architecture helps to really understand the decisions that need to be made and to ensure that the decisions are made based on the facts.
Each iteration of the enterprise architecture processes needs to be aligned to the speed at which an organisation needs to make decisions.

In this way enterprise architecture be made agile. At the enterprise level, it’s not about agile development but agile decision making.

Can Enterprise Architecture be Agile?

 

Are the rapid Agile development approaches compatible with the longer term strategic planning approach of Enterprise Architecture?

Maybe ‘agile’ is just a very overloaded word and we should instead talk about Iterative and Incremental Enterprise Architecture? 

One of the main concerns I have always had is that the concept of ‘Agile’ is closely associated with ‘Quick and Dirty’ in the minds of many clients who are happy to trade off quality for rapid development. The concept of Agile and of Enterprise Architecture do seem at first glance to be incompatible – you wouldn’t really want to develop a quick and dirty enterprise architecture especially where the impact is strategic, long term and very costly. It doesn’t matter if you have to refactor a solution a few times to get it right for the current set of user stories, but refactoring the whole organisation is less feasible. 

I am fully behind the idea of an iterative and incremental approach to both developing an Enterprise Architecture (as described in TOGAF9 and FSAM) as well as for solution development (with RUP, FDD, Perspective, DSDM etc), but don’t want to encourage low quality outcomes that can result with pure agile approaches like XP. 

I always found the original XP process to be rather anti-Analysis and anti-Architecture but I believe that both Analysis and Architecture are very necessary in the appropriate context and scale. 

For developing a Solution I often used to advocate having two parallel processes that might be called Agile Analysis and Agile Development with the Agile Analysis process feeding requirements/user stories into the Agile Development process.

Are the rapid Agile development approaches compatible with the longer term strategic planning approach of Enterprise Architecture?

Maybe ‘agile’ is just a very overloaded word and we should instead talk about Iterative and Incremental Enterprise Architecture? 

One of the main concerns I have always had is that the concept of ‘Agile’ is closely associated with ‘Quick and Dirty’ in the minds of many clients who are happy to trade off quality for rapid development. The concept of Agile and of Enterprise Architecture do seem at first glance to be incompatible – you wouldn’t really want to develop a quick and dirty enterprise architecture especially where the impact is strategic, long term and very costly. It doesn’t matter if you have to refactor a solution a few times to get it right for the current set of user stories, but refactoring the whole organisation is less feasible. 

I am fully behind the idea of an iterative and incremental approach to both developing an Enterprise Architecture (as described in TOGAF9 and FSAM) as well as for solution development (with RUP, FDD, Perspective, DSDM etc), but don’t want to encourage low quality outcomes that can result with pure agile approaches like XP.  

I always found the original XP process to be rather anti-Analysis and anti-Architecture but I believe that both Analysis and Architecture are very necessary in the appropriate context and scale. 

For developing a Solution I often used to advocate having two parallel processes that might be called Agile Analysis and Agile Development with the Agile Analysis process feeding requirements/user stories into the Agile Development process.

I’ve started this as a discussion on the LinkedIn group on Agile Enterprise Architecture.

How do you differentiate between a Business Function and a Capability?

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.

Sparx Systems’ Enterprise Architect tool now supports TOGAF

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

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!