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.

ArchiMate 1.0 Specification is published by the Open Group

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…

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.

Does Enterprise Architecture stifle innovation?

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.

Do you really need Enterprise Architecture?

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? 

Does Enterprise Architecture threaten the Business Managers?

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.

Does an Enterprise Architect need industry experience to be successful?

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).

Enterprise Intelligence Corps

An Enterprise Architect will certainly spend time creating models of the current state and the future state and the transition roadmap between them. This modelling is done in order to provide a full an coherent overview of the whole enterprise and a knowledge base, which in turn is used to support the strategy and planning activities for the enterprise. The Enterprise Architect function uses these models to support the strategic decision making for business changes, especially for IT enabled business changes. The Enterprise Architecture function also governs the implementation of the change via implementation programmes, and ensures their continual compliance and provides design assurance. 

I often compare this Enterprise Architecture function to the Intelligence corp in the military.

• The C level executives who make the decisions about the enterprise are like the generals and politicians who make strategic statements
• The Programmes and Projects in an organisation are like the divisions and battalions who do the actual fighting
• The Enterprise Architecture function is like the Intelligence Corps helping the C-level executives to understand the strategic and tactical environment, their capabilities, information about possible actions to take, and to make the best informed decisions about going forward and winning. 

Just as the military needs its intelligence officers, so does an organisation need its Enterprise Architects.

Using the Viable System Model as a basis for an Enterprise Architecture Framework

I sometimes describe Enterprise Architecture as a realisation of the System 4 (focusing on strategy/future/intelligence) in Stafford Beer’s Viable System Model (VSM).  Or as a combination of System 4 and System 3 (focusing on Audit/control/governance).  This reference to VSM doesn’t work so well as unfortunately as most people are not familiar with Stafford Beer’s work and will just give you a blank pitying look… but I think it is a good approach to consider.

For more info on VSM look at http://en.wikipedia.org/wiki/Viable_System_Model.  

I created an EA framework based on the VSM a while ago, but have not yet found a client that was interested in using it. If anyone is interested then you can see this at  http://iea.wikidot.com/vsm and download a spreadsheet version.

Tom Graves has also done some intersting work in this area, linking Services to VSM (http://www.tetradian.com/download/tet-vsm.pdf).

Is an Enterprise Architect just a facilitator?

A recent question asked whether an Enterprise Architect should just be a lone facilitator in an organisation.

All the organisations that I have supported have done enterprise architecture differently but in none of them is an Enterprise Architect just a facilitator. 

They need to gather and analyse knowledge about the organisation, communicate that knowledge, make key decsions about IT enabled business change and IT strategies, support the business strategy and it’s execution with a and business operating model, develop current state and future state EA models, develop a roadmap for the transition between them, deal with governance, compliance and design assurance for the programmes and projects that will be needed to execute the strategies and realise the future state etc. 

Broadly, I reckon 40% of the time is spent communicating about ROI and what the EA is and why it should be used. Another 30-40% of the time on the governance, compliance and design assurance activities, only leaving the remaining 20-30% for the strategy and future state enterprise architecture work.  To do all this an EA team is definitely needed. One person would just not provide sufficient bandwidth for all the work that needs to be done to be effective. 

I would say at minimum the EA team should have: 

• one person to lead the EA team and to define the vision, EA framework, EA processes etc. 
• one on IT strategy
• one on Business architecture
• one on Information/Data architecture (including data management stuff)
• one (or more) on Application Architecture (with maybe some further specialists on Integration and security) 
• one on the infrastructure architecture
• one to do PMO activities and manage the EA tool and reporting needs

Clearly some people can perform multiple roles, so the minimum number of people can be slightly less than the number of roles but not much. EA teams that I have helped establish have often been around 10 – 12 people altogether. This is probably the most efficient size of a team to manage anyway. In addition to the EA team there will also be many other solution architects or segment architects that are assigned to the programmes and projects outside of the EA team, but which are usually regarded as part of a virtual EA team with a dotted line reporting on EA matters to the Chief Enterprise Architect.  

I believe that Enterprise Architects should very much get involved in supporting the C-level executives making strategic and policy decisions especially about strategic business change that are IT enabled. There are a number of EA teams that are now being called Strategy and Architecture teams, where the strategy is generally just the IT strategy. 

The EA team will work on a number of strategic Issues and hot topics especially where there is a huge change and cost impact. In some cases they will make recommendations about strategic decisions to an Architecture Review Board or equivalent who will approve them. After that the Enterprise Architect will ensure through governance, compliance and design assurnance processes that the strategy and architecture decisions are implemented in terms of strategic portfolio of changes (EA Roadmap), programme portfolios and project requirements. And so on… 

This is more than just facilitation.

Essential – an Open Source EA tool based on Protege

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

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

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

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.

Business Architecture is part of Enterprise Architecture

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.

What is an Enterprise Architecture Blueprint ?

I recently saw a discussion about the word Blueprint in regard to Enterprise Architecture which reminded me of confusion I’ve encountered with some of my clients.

I regard the word Blueprint to be another name for the Future State (to Be ) Enterprise Architecture model content. this is my preferred meaning.

I have also worked in an EA team that regarded the strategy, principles, Goals, Objectives and requirements as the Blueprint layer on top of the usual 4 EA architecture domain models (i.e. Business, Information, Application and Infrastructure Architecture models).

In regard to the same discussion, I have learnt about FSAM which uses word Blueprint with my preferred meaning.

FSAM can be see and downloaded from http://www.fsam.gov/index.php.  I recommend that Enterprise Architects take a close look.

Archimate and TOGAF 9’s EA Meta model

I’ve been using Archimate since 2004 after coming across it in the Netherlands. It fills a gap in the discipline of Enterprise Architecture by providing a well thought out EA meta model that supports modelling at an enterprise level and integrates well with SOA, BPMN, UML modelling at a solution level. When I’ve explained Archimate to my clients, it has been widely seen as making a lot of good sense and easily understandable. Early EA efforts have often been no more than Enterprise IT Architecture that leaves out the Business Architecture and frequently also the Information/Data Architecture domains. Archimate unified all the architecture domains very well. It is good that Archimate has now been adopted by the Open Group. It was a shame that it wasn’t adopted for TOGAF 9 but should be more influential in TOGAF 9.1 and I expect it to become the defacto global EA modelling language standard by then. TOGAF 9 has now an EA meta model but it has some gaps and awkwardnesses that full adoption of Archimate should address. One area that I’d like to see Archimate be extended is integration with the Business Motivation Model (BMM). the TOGAF 9 EA meta model already has some concepts from BMM, but lacks the clarity and quality of Archimate.

Archimate User Group in the UK?

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

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:

• Archimate
  
• TOGAF
• zachman
• DoDAF
• MoDAF
• FEA RM
• SAP EAF
• IAF
• BPMN
• UML
• DFD
• ERD

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

More than 3 flavours of Enterprise Architect

Jeff Carlson has written an interesting post on The 3 flavors of Enterprise Architect.

Personally I have never come across an Enterprise Architect with an Operations background, although I think that this type of Enterprise Architect would be useful for many organisations. The Operations viewpoint is a key input to overall business and IT strategies, but often this input only comes from a ‘Manager’ and not an Architect, and is consequently less valuable.

Many Enterprise Architects come from a Technical/Solution Architecture background where they have only ever been working at a project level, leading the development and integration of software solutions and are capable of deep diving into very technical domains and programming subject areas. These types are very critical at a project /solution level, but many organisations I have spoken to are less keen on them as Enterprise Architects, because they are not so good relating to the business and executive stakeholders or indeed anyone outside of the IT organisation. Often however they end up as Enterprise Solution Architects in a Technical Design Authority type of Enterprise IT Architecture team. Organisations that have these TDA kind of EA teams also tend to have completely separate Business Architecture teams.

For myself I class myself as in another category of Enterprise Architect – One that has come up the Systems Analyst/Business Analyst/Process Improvement/IT strategy/IT management route to becoming an Enterprise Architect.

I focus on Strategy, Business Architecture, Information Architecture and Application Architecture, but far far less on Technology and Infrastructure Architecture.

I find that my kind of Business Strategy/Business Architect kind of Enterprise Architect is becoming quite fashionable, even the more so since Technology and infrastructure is an outsourced  commodity these days, and many application architectures are primarily integrated assemblies of COTS applications with just a few core business applications being developed by offshore development partners.

Elevator pitch for Enterprise Architecture

I have been reading Andy Winskill’s blog on his suggested Elevator pitch for Enterprise Architecture – ‘Enterprise Architecture is about the identification and realisation of Competitive Advantage‘.

I think this is an excellent pitch that has the benefit of being concise and focused on the business language  of senior executives.

My own elevator pitch is ‘Enterprise Architecture is the bridge between strategy and execution‘.

To expand on this pitch, I usually point people towards the excellent ‘Enterprise Architecture as Strategy‘ book by Jeanne W Ross et al.

I also sometimes describe EA as a realisation of the System 4 (focusing on strategy/future/intelligence) in Stafford Beer’s Viable System Model.  Or as a combination of System 4 and System 3 (focusing on audit/control/governance).  This doesn’t work so well as an elevator pitch unfortunately as most people are not familiar with Stafford Beer’s work and will just give you a blank pitying look…

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.