In the recent post at http://tinyurl.com/mg9k7h

‘ Is it Enterprise Architecture or IT Architecture?’,  the author asks whether Enterprise Architecture should be renamed?

I see this argument from the other way around.

I would say that there has always been a difference between Enterprise Architecture and technical architecture.

The former has its origins in the Zachman Framework which has always included the business architecture aspects.

Technical architecture has evolved to become IT architecture and IT planning.

Most organisations have kept business architecture and IT architecture separate because of the typical separation of responsibilities within an organisation.

They like to keep IT in there place so to speak.

The language of IT architecture has claimed that it now deals with ‘enterprise’ level software, i.e. software applications like SAP that are used across all the business areas. For this reason many IT architecture efforts now rather erroneously call themselves Enterprise IT Architecture (EITA) or Enterprise Architecture, whereas in fact they still only address IT architecture subject matter.

So when people claim to have been doing EA this is likely not to have been actually true and the ‘inclusion of Business Architecture as one of the domains of EA’ is somehow a further misrepresentation.

EA has always been a method for ‘architecting the enterprise’, it’s just that IT Architecture is trying to claim EA’s clothes.

The move from TOGAF 7 to TOGAF 8 and now TOGAF 9 illustrates this path.

Many organisation’s have yet to truly understand that EA is different from EITA.

As someone who has been trained in the Zachman Framework and IFW since 1995 and done ‘real’ EA, it is clear that IT Architecture should no longer try to claim to be Enterprise Architecture, but concentrate instead on being Solution Architecture and clearly distinguish itself from Enterprise Architecture which really doesn’t need to change it’s name.

A sheep in wolf’s clothing is still a sheep.

A conversation recently reminded me of an issue I have frequently seen before.

Organisations that have not had an Enterprise Architecture function have funded all changes in projects that are funded by the business areas.

The result is that the first project that needs new infrastructure or new application services that will be shared across the whole enterprise are obliged to seek funding for it on their own. Subsequent business sponsored projects can then reuse this new infrastructure or shared enterprise service without funding any part of it.

However is also not uncommon to find that the new projects in the other business areas don’t actually realise that there is anything that can be reused and can get quite a long way down the road developing their own new applicattions, services or infrastructure that duplicate the functionality before realising they could have reused an existing capability. In some organisations I have seen, the outcome is a large amount of duplicated functionality and therefore additional costs.

With an Enterprise Architecture function in place the EA governance process should prevent projects duplicating functionality, but the funding remains based on the business areas budgets.

What is needed for infrastructure chages and application services and applications that will be used by multiple solutions from mutliple business areas is enterprise level funding. With this funding model, a business area would fund the business specific parts of the solution that a project is delivering and the cross business area functionality would be funded from an enterprise level budget, sponsored by the enterprise architecture review board. Some projects will be initiated that are purely sponsored by the enterprise and not by any of the business areas.

This funding model seems an obvious approach to have in an organisation with an enterprise architecture function in place, but so far I have never encountered it.

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.

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.

The new ArchiMate 1.0 specification can now be seen at  http://www.opengroup.org/archimate/doc/ts_archimate/

See the Open Group press release at http://www.opengroup.org/press/21apr09.htm

This is the tipping point…

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.

Many stakeholders see Enterprise Architecture teams as overly bureaucratic ivory towers. They think that too much bureaucracy prevents innovation.  I agree that the balance between bureaucracy and innovation is important, but innovation is and essential part of what enterprise architecture is aiming for.

Innovation is very important when developing a future state enterprise architecture model, and trying to realise the organisations’ strategic requirements.

Too much focus on developing a 100% complete current state enterprise architecture model can seem like bureaucracy to many stakeholders and can be seem to be to formulaic in their support of dreaming up strategies. 

Innovation thrives on creativity, but it also seems to me that innovation can be stimulated by examining the gaps and lack or relationships between things, which is where analysis of the current state enterprise architecture model is valuable. 

If you don’t know where you are coming from then how can you dream about where you want to get to?

Digressing for a moment, I have often found system dynamics modelling (http://en.wikipedia.org/wiki/System_dynamics ) of the cause and effect relationships between objects (causal loop diagrams, stock and flow diagrams), popularised by Peter Senge’s The Fifth Discipline book ( http://tinyurl.com/dmghbb ), to be a useful approach for analysing how a system works. iThink is a nice tool for doing this sort of modelling. 

It would be nice to see such approaches being integrated within the Enterprise Architecture discipline and provided by EA tool vendors.

In the DYA book: Building an Enterprise Architecture Practice there is a nice image that illustrates different architecture perspectives, where an organisation can work WITH Enterprise Architecture or work WITHOUT Enterprise Architecture.  

http://tinyurl.com/dnabju 

Organisations that don’t use Enterprise Architecture can certainly still be effective. But how well are they really doing? 

The problem is that the enterprise architecture knowledge will be scattered amongst a large number of peoples heads rather than recorded in an Enterprise Architecture repository acting as a knowledge base. 

There are two types of knowledge: explicit knowledge and tacit (implicit) knowledge. 
In an organisation that works without enterprise architecture, their knowledge is tacit and implicit rather than explicit, and will be lost when people leave the organisation. 
In an organisation that does use enterprise architecture, the knowledge is explicit and the EA repository will become a lasting knowledge base, independent of staff, and will be capable of supporting strategic decision making more efficiently once it has been established. 

Without Enterprise Architecture, organisations will not have the time to identify all the relevant facts needed by decision makers. This will lead to short term knee jerk decisions. These organisations tend to end up with knowledge silos. 

With Enterprise Architecture, organisations will have fewer silos and more knowledge about the interdependencies and relationships across the silos and thus be able to make evidence based policy decisions, and have the time to engage in long term thinking and ultimately make better decisions. 

It is interesting to consider whether the current credit crunch in the financial markets may well be the result of banks not yet having a sufficiently mature enterprise architecture, or indeed as result of working without enterprise architecture? 

Enterprise Architecture is still seen as coming from the IT department despite its wider Business and IT context, so the business managers distrust of an Enterprise Architecture team can be understood. Everything goes in cycles though, and the Enterprise Architecture discipline is starting to break down the silos that the business managers unwittingly tend to propagate.

A trend I see is Enterprise Architecture gradually becoming known as Strategy & Architecture. Although bsiness managers have had control over their own business area strategies to some extent, Business Strategy and IT Strategy has always been a more centralized function that hasn’t threatened the business manager quite so much as the vision of IT taking over ‘their’ governance has. 

These days other IT centric approaches like ITIL are setting Service Strategies and are also encroaching on business managers’ control. However I like to think that ITIL is able to bridge the divide between business areas and IT department and build trust between them, by using a unifying approach to managing both Business Services and Application Services.

I see maturing organisations merging approaches such as Strategy Planning, EA, ITIL and COBIT and thereby breaking down the distributed versus centralized and Business versus IT issues. Business managers do generally understand that an Enterprise Architecture function is required to integrate all these approaches. To keep business managers happy the best practise is to make them members of the Architecture Review Board that approves Enterprise Architecture decisions and recommendations.

This way although the business manager no longer do the work but they still have the control and feel less threatened by an Enterprise Architecture team.

Should an Enterprise Architect have generic skills (in TOGAF or Zachman for example) or should they have industry specific experience to be successful?

The success of the Enterprise Architect is dependent on their perceived value to the stakeholders balanced against their perceived threat to established senior managers who feel threatened by them.  Communication is key and takes up at least 40% of the time.  

When the Enterprise Architects have a good understanding of the business and experience in the industry then communication with stakeholders is much easier. 

When the Enterprise Architects have a too generic a focus and less industry specific experience then communication is much harder. 

However, I have seen organisations where there isn’t really any true enterprise architecture function, but instead there are Business Architects, Segment Architects (see FSAM http://www.fsam.gov/index.php ) and Solution Architects scattered amongst the business units (lines of business).  

• Each Solution Architect is typically only focused on a specific technology domain or vendor product used by a specific business unit
• Each Segment Architect is focused on a specific business domain or set of business services and/or application services
• Each Business Architect is focused on the business operating model or change programmes for a business unit

All of these roles will be expected to have extensive industry experience. 

This focus often leads to a silo approach with business units working as independent fiefdoms without concern for the benefits to the organisation as a whole.  It also results in less improvement from the enterprise perspective.

I think that the best Enterprise Architect team is made up of generic enterprise architects with a reasonable knowledge of the industry together with Business Architects, Segment Architects with Solution Architects (in a virtual EA team) with more industry specific knowledge and experience.

This is a Matrix management approach that balances the needs of the enterprise as a whole against the needs of business units. Since it is often the business units that hold budgets, they are often the ones that want employees to have industry specific experience.  

Another driver for ‘industry specific experience’ is that many organisations want to learn from an enterprise architects’ experience with one of their competitors. Often this is a not so subtle form of industrial espionage.  Obviously an enterprise architect should be professional about not revealing the secrets of a previous employer, but it is difficult to forget best practice, which is what the new employer finds valuable. For a newly hired enterprise architect it is a balance between improving the way things are done using generic enterprise architecture approaches and doing things the way it has always been done and improving nothing. 

An Enterprise Architect does not want to be too busy chopping down trees (just reusing their industry experience), to take time out to sharpen their axe (reusing generic enterprise architecture best practices).