Song of Deborah

The Challange - Architecture is like food because...……..!

On the discussion board for a LinkedIn group Andrew asked - Architecture is like food because...……..!

 

This is a scary thought after reading the Melissa Cook - chicken analogy! ; )

Doing EA is like carving chicken? I discovered this Nov 08 article by Melissa Cook while looking for an example Green IT EA principle - what do you think?
http://www.computerworlduk.com/management/it-business/it-organisation/opinion/index.cfm?articleid=1877&pn=1
It is an odd analogy, I don't agree as it is too simplistic but strangely I can see how she got here.

Mmmmmm……………. for me architecture is like……….

Vitamins – often we are not sure of their true value; experts are always disagreeing as to their worth; we (the general public) continue to take them (replace take them with do it for EA) just in case; for some the dose is for short-term benefit i.e. Berocca after a big night out; for others it is just a habit they never think about – got into it during a fitness kick and kept taking a daily vitamin and the true believers never miss a day and combine they vitamins, minerals and herbals because they know that they will provide a long term benefit.

Architecture is much the same:

• In many organisations they do it but are not sure of – nor do they care about – the true value. Others are doing it so they might as well, it won’t hurt.
• The experts are always disagreeing about architecture’s value – IT strategy experts will tell you it is all about the strategic roadmap; operations people will tell you it is about ITSM; project experts will tell it is all in the project management methodology etc. Most organisations will try all these things and keep doing architecture in all the wrong ways – bending and changing with the management fad of the moment.
• Architecture for short term gain is very common – solution architecture oft comes in this guise. I always cringe when I hear the phrase “we need a xxxx architecture – get someone in to do it”. There is this belief that you can create an xxxx architecture out of thin air in the 3 month consulting gig – no understanding that this is a long term process.
• I think the worst organisations are those that just keep doing it badly and never questioning why. The follow a framework of method religiously, plodding along in their architectural void never understanding where they can be adding real value. Never understanding their customers and tailoring their deliverables to suit. Giving the rest of us a bad name.

The true believers! This group are a small minority who really understand the value of architecture and apply it in day-to-day and strategically in their organisations.

 

Enterprise Architecture KPIs that demonstrate the value of EA to the business and IT

One EA group doing business architecture used some key business metrics: number of dispatch per call (based upon technicians dispatched per call to the call centre) and CSO training time (they reduced the number of applications that were used by call centre staff and thus reduced their training time). I liked these because they could have represented the exact same measures in “IT” speak but they didn’t they used concepts that were important to the business.

Here are some other good success stories from Gartner (a great research paper on EA and cost optimisation by Bruce Robertson), sadly IT focussed: 1) A retail company mapped projects to business strategies from EA vision, some had strong linkages (to more than one strategy) and some had no linkage at all. They found the ERP upgrade could be put off so they did indefinitely (>3 years now) and saved > $2M. 2) Lots of rationalisation stories – from 35 unique SAP implementations to 2, estimated savings: 10 million euros annually, 278 sites and Data Centres reduced by 75%, portal consolidation: from 2,000 web sites to 40 hubs, 650 servers eliminated and reduction of ERP staff in shared service centres from 2,400 to 1,200 in 2 years. 3) Some innovation and business savings - added reverse auctioning to e-sourcing, reducing costs by 25% and e-procurement initiative using SAP SRM helped optimise the procurement process, over 10 million euros saved annually.

If you want to measure value think about where to focus your attention – this statistic is very interesting - Average IT Spend in 2007 = 4.1% Revenue, Average IT Spend in 2007 = $12,471 per Employee, Average IT Spend in 2007 = 5.9% Operating Expense What about the other 94.1% of the expenses? Think beyond IT because it has been bled dry – how can you express your EA value in business focussed KPIs?

The biggest challenge you have with EA measurement is that the work architects do occurs before projects are implemented and is often not recognised. Track the involvement of architects in projects prior to implementation – at concept/feasibility phases and then piggy-back on the project KPIs. The global Chief Architect at GM tells the story that he saved the company $3.7 million in his first month on the job. All he did was rationalise their ERP portfolio down to 1 instance of SAP. Now you and I know that this would have been a huge program of change over several years to retire all the old apps and migrate everything onto SAP but he did not care he took credit for the overall saving because it was the EA work that identified this opportunity. This is the type of thinking you need to successfully measure EA – no one will give you credit for your hard work in the early phases of a project lifecycle that generated the success of that project and its relative KPI/ROI. Use concepts like probable cause and pragmatic justification. If you show probable cause that EA directly contributed to the success of a project – take the ROI/KPI of that project as your own – this is pragmatic justification.

What are the common deliverables at the end of Business Architecture engagement?

There should be no independent business architecture deliverables. What you should have a set of EA deliverables of which there are business architecture artefacts representing the business view. You cannot do business architecture in isolation; you will just end up with another organisational silo or similar situation to what we had in the early information architecture days – a conceptual data model for the entire organisation that took so much time and effort to develop that it broke people and then was of little or no use to anyone. In EA you need the BITS – business, information, technology and solution architecture views to every problem you are trying to solve or every strategy you are trying to execute. I do not think there is a modern organisation that conducts business independent from information, applications and technology if there is then there would be separate BA deliverables.

Think carefully about what you are trying to achieve and if it is just creating THE business architecture then you will be heading down a risky path. Instead think about using business architecture deliverables to make better future state decisions. Then think about what these will look like and as Harish mentioned they will vary every time. Ask your self this question – “What information do I need to make a decision about this future state architecture?” Then define the deliverables that will help.

How should the Enterprise Architecture function be introduced (and implemented and used) to ensure that it delivers value to the business?

On names - the best I have heard over the years was the "Simplification Office" -
Great name! The best label is – IT Planning and Architecture or if you are keen to stir up the business people - Enterprise Planning and Architecture but consider what you are being brought into the organisation to achieve and use a label that reflects that.

On implementation - think short cycle iterations. Don't think of what you are doing is creating "THE" anything just focus on what, how and when. What I mean by this is identify critical pain points in the organisation and key strategic imperatives and pick 3-5 things you are going to solve using EA in this iteration (I would limit yourself to 6 months) :> this is step 1 SCOPE.
Then plan out how you are going to address these things - future state/current state/ close the gap. Analysing and modelling how do I change …….the way I do business, the way I manage and use information and the supporting technology and solution portfolios ….to solve this problem or execute this strategy. :> this is step 2 ARCHITECTING.
Ensure that Close the Gap is being wisely executed within the PMO. Then evaluate what worked what didn't and make sure all the architectural information you created in step 2 is sorted according to your framework/taxonomy, shared and communicated widely. Make changes to the things that did not work well :> this is step 3 VALIDATE
Celebrate your success - loudly - and start all over again.

What you will achieve with this approach is the continuos development of THE enterprise architecture while remaining topical and solving real world problems for your organisation. If you commence an EA program thinking you are creating THE enterprise architecture and methodically go about doing that you end up not focussing your skills and energy on what is important to the organisation – very risky and IMHO just plain stupid. If there is one lesson we have learnt in the past 12 years is that EA for EA’s sake is a waste of time – if you are not helping your company move forward then stop doing what you are doing.
The simple iteration approach is the one that I have seen consistently work well – where many of the others you mention often fail.

How well do existing Architecture Frameworks support the development of Business Architecture?

I believe that for every strategy you want to execute via EA planning you need all the BITS – business, information technology and solution architecture. Without the business architecture you are just doing IT architecture and risk technology for technology’s sake implementations. A well-defined business architecture is a prerequisite for developing a successful EA future state and defines how the business moves in response to strategic change. It also provides both the business and IT organisation with a better understanding of the business designs for the future that the technology must support.

I agree that as a profession EA struggles with the development of this critical piece (including most of the various frameworks and practitioners). Often this is due to a lack of understanding of the business, its relationship to IT strategic change and an inability to break down the perceived vastness of the business architecture into smaller, more easily delivered elements beyond process models. Most perspectives make it too large and complex to comprehend, let alone to start to develop in a just-enough-just-in-time approach or limit understanding of all the aspects (i.e. UML models that IT understands not the business) that the business (not IT) needs to change.

To further complicate matters, many constituencies that impact the business architecture are often isolated from the EA team (as you discuss in your breeds of business architects Steve). Many other focus areas or people that act in the business architecture arena: business analysts, business process professionals, business managers, integration architects, risk and compliance professionals, HR professionals, etc. This is a considerably large group of players all trying to develop and manage elements of the business architecture and often isolated from each other.

I like to think of business architecture like I do the technical architecture as:
• Components (bricks): define individual business processes (these may be broken down into sub-processes or tasks), people, business rules and assets. The level of detail will vary from org to org.
• Domains: group business process, people and assets that reflect functional view, business units, roles, geography, and organisational structure.
• Patterns: organise processes, people and assets into groups that reflect an end-to-end perspective: i.e. business operations, product lines, business events, organisational design, and business activity.
• Services: represent a set of processes, people and assets that are delivered as a single unit and reused in this exact format every time. For example, "create new employee" adds a person to payroll, phone lists, and security; assigns a role and places it within a functional structure; aligns performance management; and so on. These may relate to business events, goals and objectives, business activity, geography, and roles. Sets of services are used for fiscal management, human capital management and performance management.

I have also seen people use Zachman very successfully to deliver business architecture – one client organised it this way – they relied heavily on the Zachman Framework for the managing constructs to the business architecture artefacts. The work products are itemised in a typical Zachman fashion:
• The how — business process model
• The why — business motivation model
• The what — information model
• The when — business event model
• The where — locations model
• The who — organisation and roles model
• The integration of all the above in a relationship model

Without business architecture you do not see a complete or holistic view of where change is required to execute strategy and risk filling holes with technology when it may be unnecessary. IT is just part of the operating fabric of the business and in modern organisations EA without comprehensive business architecture will become obsolete.

the variety of ways that organizations "apply" Enterprise Architecture

This frustration is very common - many clients I talk to - CIOs and/or enterprise architects are equally confused. I think this related to two issues 1) no one really understands EA well and 2) we have a culture of tactical organisations where strategy is what we are doing in the next 12 months. EA at Gartner is defined as … the process (it's a process AND a thing)…of translating business vision and strategy… into effective enterprise change (if no change is needed, then no EA is needed)…by creating, communicating and improving the key requirements, principles and models
that describe the enterprise's future state and that enable its evolution (EA produces the creative constraints that bound implementation decisions). The scope of the enterprise architecture includes…the people, processes, information and technology of the enterprise, (architecture is NOT just about technology)… and their relationships to one another and to the external environment.
Enterprise architects should compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them BUT in most cases we create paper architecture – masses of paper that does not drive change, execute strategy let alone address business challenges.
One of the thing I like about AgileEA are the sprints – rapid cycles that address real challenges, use architectural skills in analysis/modeling/planning and identify the change required to solve probelms rather than the legacy approach to EA “build it and they will come”.
Start to think how you change your thinking – develop rapid iterations that address challenges and solve problems by identifying change rather that creating documents and models that are architecturally sound but of no use. Identify your customers and what they need to do their jobs better. The biggest challenge will be getting your organisation to think beyond the next budget cycle (strategic thinking) – developing roadmaps (the Albright Strategy Group has some interesting roadmap information) can help.

Driving Business Value from an Enterprise Architecture Roadmap

For me measurement is about PROVING EA's value and you need good business aligned measures to do that. To get really good business aligned measures you need to understand how each business stakeholder measures success - ask how do they get their bonus and then how is EA contributing to that. Here are some examples I recently published on www.gartner.com :

• Percentage increase in market share
• Improved time to market for new products
• Target Market Index = Relative market size X (1 + relative market growth rate)
• Market Coverage Index = The number of countries an organization sells in weighted by size of revenue/target market global industry revenue
• Number of new processes identified and improved
• Number of environmental /industry trends articulated in future state architecture
• R&D Success Index = New products launched in past 12 months
• Number of new business plans with EA involvement
• Increased anytime, anywhere anyway access to information
• Market Share Index = Revenue of organization's offered products and services/ total revenue of ISIC-code selected industries
• Percentage of time each EA role in strategic and business planning process
• The Product Portfolio Index (identifies and validates current and projected customer needs in existing and targeted markets).
• Opportunity/Threat Index = Sum (Market Share Index for top five revenue leaders)
• Customer Care Performance = Customer care requests within SLA/total customer care requests

However, the BIG challange in EA measurement is not metrics.

Having good metrics is important but the big problem is defining EA's contribution to any metric - this is the biggest challange, and for many EA teams, it becomes an insurmountable task. There is often no direct link between the work done by EA and the successful end result - many other things contribute along the way and there is often a significant time lag between EA planning and benefits realisation at the end of a project. Quantitative methods for collecting measurement data for EA are often unconvincing, because there is no direct one-on-one link between these metrics and EA contribution.

Try the "before and after approach", before EA was in place or yearly, as EA matures — and compare them to subsequent results. Alternatively, collect metrics that relate to business performance with EA versus performance without EA.

The important difference is that no claims should be made that these improvements are the direct causative result of the EA program. Such a connection cannot be proved, but explicit linkages must be made. The various improvements may come from many other sources.

Often EA needs a scoping activity at Gartner we call this step the Business Context and its output is the Common Requirements Vision (CRV) - for this iteration what are our scope, goals, vision and requirements then start the future state/current state analysis. If you have the strategies and business sucess areas you are focussed on defined up front then you can PROVE that the business strategies were impacted by EA (hopefully successfully). If you have no scope or objective what can you measure your success against?

Take what is possible by association. The evidence submitted becomes circumstantial evidence. EA is likely to have caused these effects, but the link cannot be proved. This association is a positive thing. We make an effort to show "probable cause" that EA led to the desired improvements and leave it at that.

OK More EA - I can't help it is what I do

I have been blogging away on LinkedIn discussions and want to save them all here in one place. Bear with me.

EA Reading Suggestion - from LinkedIn

I could break it down like this :

strictly EA books ---------------------------

"Enterprise Architecture As Strategy" by Jeanne Ross, Peter Weill, and David Robertson

" Building Enterprise Information Architectures: Reengineering Information Systems (HP Professional Series)" , Melissa Cook

 "Architecture of Integrated Information Systems: Foundations of Enterprise Modelling" by August-Wilhelm Scheer

books on change, communication or strategy ----------------------------------------------------

1. The Back of the Napkin by Dan Roam: http://thebackofthenapkin.com/

2. Tribes by Seth Godin: http://sethgodin.com/sg/

3. Made to Stick by Chip & Dan Heath: http://madetostick.com/

4. Presentation Zen by Garr Reynolds: http://www.presentationzen.com/

5 "The 7 Levels of Change" by Rolf Smith

6 "Communication Land Mines" by Marty Clarke

7 "How Buildings Learn: What Happens After They Are Built" by Stewart Brand

8 "The Art of the Long View" by Peter Schwartz.

9 'The master masons of Chartres' by John James

10 Blue Ocean Strategy by Kim and Mauborgne

11 The Heart of Change by Kotter and Cohen

books on business matters ----------------------------------------

"The Portable MBA." by Robert F. Bruner, Mark R. Eaker, R. Edward Freeman, and Robert E. Spekman

"Business Process Management: Concepts, Languages, Architectures," by Mathias Weske.

EA Skills & Certification Comment from a LinkedIn Discussion

The big problem I have with The Open Group’s approach – it is expensive to be certified and in my experience EA certification is never mentioned when applying for EA jobs. In fact I have deleted the qualifications section of my CV two years ago and no one has ever asked for that information.

Exposure to and/or training in multiple methods is the better then relying on one – DODAF, Zachman, TOGAF, EA3, Agile EA, etc and take the best of each and work out how to apply it is a better practice that certifying in one. If interviewing an architect now I would ask for strengths and weaknesses of each and expect an educated and informed answer. I would not look for certification - it is an expensive myth.

The biggest challenge in finding someone who stands out from the crowd is someone who can really make EA work. So many practitioners I meet are theorists and are significantly challenged to deliver EA successfully in an organisation. Is this because they try and follow a method blindly?...... Sometimes. Is it because they lack the skills to deliver EA?...... Sometimes.  Is it because they dwell on the noun – creating THE enterprise architecture rather than the verb – doing future state planning and seeing it executed in projects?….. Often.

Mostly it is because they lack leadership. No matter what you are doing in the EA space you need excellent leadership skills to make it successful. Something as simple as making a stand of a target state for a technology domain requires: 1) Bravery – putting yourself out there and risking getting shot down, stepping on all the toes of people who wanted blue boxes not red boxes because they are better etc. 2) Facilitation – bringing together all the views and challenges and directing that energy toward a final solution – that is hard work. 3) Collaboration – involving people and building relationships. 4) Negotiation – hearing and absorbing people’s views and opinions (not just listening but really hearing) and finding common ground. These are all leadership skills and no EA training will give you these.

I would rather send my architects on a leadership course and coach them in good leadership then get them certified in an EA framework. I would also expose them to as many EA approaches as possible and get them thinking about action - doing EA (i.e. future state -> current state -> close the gap…. one strategy/issue at a time) not creating things.