Complex Enterprise System“Simplicity does not precede complexity, but follows it. Alan Perlis
Last week’s IIBA (International Institute of Business Analysis – London Chapter meeting, kindly hosted by Credit Suisse) revealed a wealth of opportunity.

While the financial markets are struggling with low growth, increased volatility, low margins, and the enveloping burden of increased regulation (e.g. Frank Dodds), the requirements for IT change still come…and come…to do more for less.

Any company in possession of an IT estate consisting of duplicated systems, application and interfaces (see Conway’s Law http://en.wikipedia.org/wiki/Conway’s_law), must be in want of simplification.

The opportunity… is to step back from tactical solutions and consider:

  • the lifetime cost of the change for RoI calculations,
  • how to leverage and re-use the existing estate,
  • consolidating systems and ‘clean up’ of the infrastructure
  • adopting standard data and methods

The cleaner the operating model, the easier it will be to:

  • show regulatory compliance,
  • find the truth in data
  • ease estimation of the costs of Acquisition + Merger integration

When this also allows progress toward the architect’s Target Operating Model (TOM), it spreads a common language and understanding across the business.

So… the recommendation is to make time for real design, take steps towards the TOM, and reject the tacticals!

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” Antoine de Saint-Exupery 

Caution workforce in the road!

What would your reaction be if the workforce in the road, fixing the road, did not have any tools or machines to do the job?

Frustration at the waste of time in the resulting traffic queue?

What would be your reaction if the washing machine repair man turned up without his tool kit, without a diagram of the appliance and without access to spare parts?

Refuse to pay the bill?

A security company providing security without enough staff

Questions in Parliament?

How is that so many Enterprise Architects can do their job without the tools of their trade?

Often Enterprise Architects are missing vital parts of their tool kit:

  • Standards
  • Principles
  • Reference architectures
  • Models of the Organisation
  • Application Landscape
  • Analysis and design tools
  • Information sources to feed the analysis tools
  • Stakeholder analysis

Worse than this they seem to lack the basic tools to be able to create the EA tools they need such as the processes to maintain the models, principles, guidance and governance.

Do you wonder why EA gets a bad name?

I am not suggesting that we go back to the old EA approaches

  • Boil the ocean documenting the current state
  • Tons of detailed standards (always out of date)
  • Heavy handed governance that increases costs,  misses deadlines and the point

And any of the other EA anti-patterns

Togaf 9.x of course points us at lots of artefacts and things to do, it is supposed to. We do not have to do them all, we can mix and match – What happens when we mix and match ourselves out of TOGAF9.x in all but name? Are we no longer doing architecture?

There are precedents for this situation:

SSADM was created and adopted, but everyone picked the bits they liked or could do. No one could afford to complete the whole SSADM – Especially with paper and pencil (there were few tools around).  SSADM became discredited; Every claim of compliance was subject to interpretation.

A similar thing happened to PRINCE.

I guess that there are many other examples of the dilution of the good practices until they are no longer effective.

Will this be the fate of TOGAF?

Are we architects no longer doing architecture?

Last week I attended the EA & BPM Conference in London. This is an interesting event covering the Holy Trinity of Enterprise Consulting; Enterprise Architecture, Business Process Management and Business Architecture (the key filling pulling this sandwich together).

This was the second year they have collocated the BPM Conference with the EA Conference and I think this makes for a really interesting mix. It also highlights the rise of BPM as a key function in the Enterprise. This was reflected in the exhibitors where BPM was a recurring theme on the majority of the stands. I found there was so much of interest that selecting a session was really tough over the course of the three days so I’ll highlight a few of my favourites.

Day one was a collection of seminars. I was intrigued by Alec Sharp’s Data Modelling seminar. Not for everyone Alec insisted on audience participation as he gradually built up his set piece of normalisation dance moves. Bizarre initially but I gradually found myself totally buying in to this. It’s a great way to reacquaint yourself with the various forms of normalisation. This was however a serious session providing tips and techniques for applying this ‘Misused Technique’. I’ll be laying out my diagrams in a more structured form and looking to apply ‘Guerilla Modelling’ where I encounter resistance to modelling in the future.

I was introduced to Blue Ocean Strategy during Jeff Scott’s Key Note on day three. He showed the use of the Strategy Canvas as a tool for developing strategy potentially making your competitors irrelevant. This was particularly interesting and BOS has been added to my reading list as a source of inspiration for my growing Business Architect’s toolkit.

For me the most challenging speaker, and also presentation attendee, was Michael Roseman. His constant reference to ‘Commodity BPM’ and ‘Cute’ ideas pushed you to think about the desired outcomes and values of your BPM initiative. Sure you need the fundamentals in place but conventional analysis and modelling techniques aren’t guaranteed to produce the innovation Enterprises need in today’s highly competitive and changeable environment. His classification of brainstorming as a child’s technique that is more often than not a hit and miss affair was great. He continued to explain that what’s needed is patterns for thinking and innovating that allow you to move towards a repeatable approach.

It was a great three days with an enormous amount of information and learning to be gained from both the presenters and in discussions with the exhibitors and attendees between the presentations. I’ve come away with new tools, techniques, ways of thinking and an even larger backlog of reading to cover. All I need is some time to sit down with a good book and a cold beer…

According to a Gartner survey presented at their EA summit in London the order of merit for the integration of EA into Business is:

1 Asia

2 South America

3 Europe

4 USA

It demonstrates that emerging economies and their developing organisations are more prepared to engineer and construct their businesses with help of the EA, than organisations in either the US or Europe.

I suspect that history is repeating itself – In the late 1970s Lean Manufacturing (Just in Time) had been developed by Toyota and had just been discovered by US businesses. Toyota, who had had a pressing need to catch up with the USA and Europe manufacturing, developed the processes originally started by Henry Ford.

In the face of competition from Japan in the 70s and 80s the US and Europe needed to catch up with Japan’s manufacturing methods and desperately copied the ideas emerging from Japan and from Toyota.

I predict that from 2013 and beyond, when the businesses in the USA and Europe realize that to compete with Asiapac and South American businesses – they too will have to re-architect and re-engineer their organisations and processes, just like in the 70s and 80s.  This time it will be the business models and the business processes created by EA that will be re-exported to the US and Europe by the developing economies.

Calling all Enterprise Architects – are we ready for the challenge?

PresentationCroppedYesterday was a busy Enterprise (EA) Architecture day – I was presenting with a colleague from Visa Europe at the Open Group conference, and then was off to the Gartner EA Summit for the evening networking event, where Smart421 was a sponsor and had a stand. Due to a rare piece of good fortune the two events were within walking distance of each other near Westminster, and so I could race from one to the other. I even walked past Vince Cable along the way – despite last week’s hammering at the polls he was looking quite chipper. More about the Gartner EA summit in another post – maybe I’ll even mention Basil Fawlty…

The presentation was about the maturing of Visa Europe’s Architecture practice, and was jointly presented with Mark Pettit (on the left in the picture) who is head of EA for Visa Europe. Smart421 and Visa Europe have worked closely on this ongoing continual improvement process since mid-2009, and so it was nice to be able to shout about our joint success. The EA world certainly needs to celebrate successes whenever it has one, because they don’t seem to be that common :). We got good interest from the audience which was flattering, including some interest in using the presentation material as a case study for an EA under-graduate university course in the US (see below).

The attendance at the Open Group event was a little disappointing I felt – maybe about 120 delegates or so, but as always I picked up some useful snippets and a few gems during the day. Your impression of an event is always skewed by which streams you chose to attend, but there seemed to be a strong focus on business strategy (measured via balanced scored card from Kaplan-Norton) and it’s relationship to EA which was interesting – I detected a shift from the historical “is business architecture really part of EA?” wrangle towards general acceptance.

There was a stronger representation from the Middle East than I’ve ever seen before at these conferences, and clearly the Open Group see this as a key growth area. I attended two very credible presentations from speakers from this region.

The final presentation of the day that I attended was related to the teaching of EA in universities, specifically Penn State in the US. Dr Brian Cameron is clearly getting a lot of traction with industry bodies and companies – with really encouraging student employment and starting salary rates. I was surprised in a recent interaction with a university in the UK that architecture in general was so poorly represented in their Computer Science degree curriculum, and so Penn State’s advances in this area show the way forward. Tomorrow’s graduates are going to be assembling solutions from cloud-based components, not writing pages and pages of Java (although this “nuts and bolts” knowledge is still necessary, I accept) – so the EA discipline is going to become an even more relevant skill over time.

"Small opportunities are often the beginning of great enterprises" - Demosthenes

"Small opportunities are often the beginning of great enterprises" - Demosthenes

Did you know that of the 500 original companies of the original S&P 500 (Standard & Poors) in 1957, only 74 of those remained in 1997 – that is a staggering 85% reduction!

Why is this?

The capital markets in the world today encourages rapid and vast growth leading to greater revenues and wealth, meaning people are expecting companies to adapt and perform to the market conditions and are not too understanding when they under-perform over the long term. Of those companies that are no longer in the S&P 500 one of the key factors that they were unable to be keep up with the changing demands of the markets and been able to be agile in entering new high value markets. Whilst change can be slow, it is always powerful!

It is having this ability to adapt and change that helps companies today to survive and a great way to help your business achieve this agility is by adopting a SOA architecture. It can really help a business create an IT infrastructure that will support a truly dynamic enterprise.

SOA is all about defining services that align and support business process, and exposing these services so they can re-used easily. It also allows these services to change independently so only aspects of business processes that need to change (as the business adapts and changes) minimising the impact on the rest of the IT infrastructure and business.

The loose coupling gained from adopting a SOA also provides abstraction from underlying systems and applications. This allows greater flexibility on consuming and invoking the capability exposed through the SOA, whilst enabling the ability to  switch the underlying systems and platforms as and when this is required.

When you consider all of these benefits you can see the agility this provides your business.

SOA is nothing new and has been around for a number of years now (and in a number of different guises) but in our opinion it is now a widely accepted mainstream approach within IT architecture, which we are seeing with a number of our clients investing and driving forwards with SOA as they have realised (and are already reaping) the benefits that it brings and how that journey can be the beginning  of a great and dynamic future.

I have just come from the 22nd Open Group EA Conference in London http://www.opengroup.org/london2009-apc/ and survived my 1st presentation to the Open Goup. I was on edge all conference hoping that no one would be presenting similar material to mine. They did not and the Sustainable Enterprise Architecture http://www.opengroup.org/london2009-apc/latham.htm remained my baby.

It has been good to have affirmation that Smart421’s EA http://www.smart421.com/solutions/consultancy/enterprise-architecture.asp proposition matches up to other’s best practices.

This conference was the launch of TOGAF 9, thankfully for my British reserve, not launched with great pomp and ceremony, nor with any Razzmatazz. A little Raz may well have re-enforced the significance of the achievement.

Judging from the mood of the delegates there is confidence in TOGAF 9 and agreement that it is solid as far as it goes.

TOGAF 9 has put on a lot of weight since it was 8, much of it valuable and not at all a middle aged spread into verbosity. Although covering TOGAF 9 at breakneck speed in a couple of presentations on the first full day was not necessarily the best use of conference time. It did show that at least 3 people know TOGAF 9 inside out – I am sure that all of the Open Group members who worked on it are as equally as knowledgeable.

Watch out for Archimate http://www.opengroup.org/archimate/downloads.htm – A meta model to describe Enterprise Architecture, you download the symbols for use in Visio, but to use it properly it needs to be installed in your modelling package. Archimate 2 is due out by the end of the year. I think that it will be a unstoppable force for architecture modelling in years to come.

There were a couple of recurring themes at the conference:-

The hole that is Business Architecture – As Tom Graves http://www.opengroup.org/london2009-apc/graves.htm pointed out IT is less than 10% of expenditure and so by inference we are missing out on 90% of the market for architecture. The hole is being addressed by the Business Architecture working group, but progress is slow and there is much to be done. I want to encourage all knowledgeable practicing Business Architects to dive in a get it sorted.

Enterprise Architects need more soft skills. We are too geeky! This may also explain the lack of progress on the Business Architecture front as the non IT people can not bear to talk to us or as Paul Homan http://www.opengroup.org/london2009-apc/homan.htm put it – they do not understand what we say and anyway we take too long to say it!

Some people were trying to extend the scope of TOGAF, Jason Uppal http://www.opengroup.org/london2009-apc/uppal.htm talking about the 10 year lifecycle of architecture artefacts. Amit Bhagwat explored the relationship between leadership, time span of control and Enterprise Architecture.

On balance there was a lot of talk about theory and not much on the practical application of TOGAF. There is great need to publish practical EA experiences and best practices.
We have contributed to the EA community, thrown in our hat with a model for Sustainable EA. It was interesting that some other presentations were near to our offering of Sustainable Enterprise Architecture – Danny Greefhorst http://www.opengroup.org/london2009-apc/greefhorst.htm talked about Just in Time architecture as part of his Pragmatic Architecture, Paul Homan talked about architecture becoming out of date quickly, if it if not used (Use it or Loose it I suppose) – Martin van den Berg http://www.opengroup.org/london2009-apc/van_den_berg_martin talked of the “Project Start Architecture” the EA Killer Application – But I think that the EA Killer app is the Project Start-up in the our Sustainable EA.

314px-Six sigma-2 svgAs it’s an interest area of mine (honest!), I had a 30 minute chat with a Six Sigma black-belt colleague of mine yesterday about how EA and process improvement methods like Six Sigma fit together. His viewpoint was interesting:

  • EA/BPM people tend to see things as a technology problem/a problem to be solved using technology first – and maybe jump to creating a “change programme” very early, i.e. tend to solutionize too quickly. Often when working with clients I see projects that have already been dreamt up in the business/change community, and so the “master plan” behind them all is never clear – and some projects are almost contradictory in their objectives/vision.
  • On the other hand, six sigma people see things as a process problem to be measured first (set up the right metrics etc), understand where that process can be improved, and then instigate change initiatives. So once the metrics are in place, it may take 6 months before you are confident with your data that you know what to do. His example was to take the business goal “increase sales conversions from x% to y%” and then set up/capture the right metrics to understand why people don’t buy, and then (and only then) drive changes to improve it. I thought this gave the magic linkage/traceability between business vision->objectives->goal->change programmes that I rarely see in the EA world (although it is often talked about).
  • His view was that the bulk of business processes in an organisation are performed by people with limited technology support. What I mean by this is that a person might deal with some post (ok – scanned and held in a CMS), decide what to do, make a phone call, check a report, escalate to their manager if necessary etc, then key the result into a system – most of the real action happens outside an IT solution. Therefore the bulk of process change and improvement options lie in the marshalling of human resources first. The “IT is just an enabler” theme was really true to him, and it occurred to me that although we say this a lot in the EA world, we don’t really mean it in the same way and with the same conviction that he does.

Even in the organisations which are reasonably mature in EA terms, it is interesting that I’ve not seen a ‘Change Process Improvement’ team having much contact with the EA team. It’s really confirmed to me that there are two camps who both believe that they should have CEO mindshare – but where neither necessarily has the full picture or skills though.

I have recently been on a course about Business Process Modelling, which gave me some other perspectives of BPM and how it can be promoted and used by companies.

Prior to the course, I have used a few BPM tools to graphically represent business processes (including IBM Business Process Modeller, Oracle SOA Suite and AquaLogic BPM tools). When using those, I have felt that their use is more related to the automated execution of business processes, through BPEL and service integration capabilities. This seems to be just a technical approach, which isn’t really the solution – although that does depend on how you classify the problem to be solved.

In working with clients, and team members, I have had numerous discussions and explanations on modelling of business processes where there is no technical view involved. It is from this approach that modelling the process can help in understanding, defining and subsequently refining or improving the operations of an enterprise. In process modelling terms, this would consist of creating the Process Architecture for an organisation. From an Enterprise Architecture, this could correspond to the Business Architecture view, where the business is represented as a series of processes operating across defined value chains.

The interesting part of the BPM course I attended was not so much around the approach and methodology described for modelling, but more about the real-world experiences, cases and examples put forward by the course trainer (who does this as a real job, not just as a trainer). Many industry speakers and research analysts are promoting the benefits of process modelling and in structuring companies around process delivery and value chains, rather than in the more common functional silos and hierarchies. The examples discussed on the course seemed to put forward a strong case for this approach (as you would expect), but perhaps with more explanation. My task could now be to summarise and promote those concepts within my own company, as well as that of clients that we work with.

A parallel was frequently drawn with the way in which manufacturing has long been structured and organised around processes, with the production line of Henry Ford being one example. Also, the quality and time controls from Deming et al being another way in which that industry has rationalised and improved over time.

In contrast, the service industry is still mostly structured in functional areas, with a process crossing over many areas and responsibilities from start to finish. That is clearly inefficient. The hand-offs between teams mean that no one person or function is responsible for the process as a whole; each functional area is mostly tasked with ‘doing their job’ and not focused on the end result of the process within which they are working. This is further highlighted by the way in which company budgets are defined. These are nearly always on an area-by-area basis, not on a process-by-process. That can result in functional areas not having any strong interest in delivering value through a complete process, merely in getting their piece of work done in the quickest, easiest or cheapest way. Generally, not the behaviour that an organisation would truly wish for.

A point I would like to repeat from the course is that processes should have objectives or targets and associated measures that cover not only efficiency, but also effectiveness and adaptability. Many measures look just at basic efficiency, which is a waste if the overall process being followed is not actually effective (why optimise a part of a process to the nth degree if that part isn’t even needed in the first place). Analysing and designing processes against such measures can give an objective outcome for any recommendations, and a way to show the gains as a result. Consider also that efficiency gains through optimising process steps may gain percentage improvements, but making larger-scale changes to the overall process may result in many-fold improvements. Figures such as reducing a process from weeks to hours, those are the major gains available to companies if they do things right.

I would think that the one take-away from my views and comments above should be that organisations can definitely be improved through process re-engineering, and that business process modelling is a great approach to achieve this in a visible way. In fact, if you spend time looking at things from a BPM perspective, you would wonder how companies can look for large benefits without such modelling and associated organisation structures.

six-sigma

Prompted by one of my EA colleagues, I’ve been reading up a bit on Six Sigma recently, and I’m surprised that I cannot find very much info on the web about the relationship between EA and Six Sigma. The best article I could find was this from Andy Blumenthal, but not much else. No real mention of any relationship to it in TOGAF 9 that I could find either.

Whilst Six Sigma has a heavy quantitative and process improvement focus to it, it is very aligned to the loftier business architecture aspects of EA and so they have very similar ambitions. I’m sure this question must have come up at various EA/Six Sigma conferences – or does this just demonstrate the IT rather than business roots of EA? All views welcome…

Follow

Get every new post delivered to your Inbox.

Join 1,122 other followers