« Get spammed by a friend – clever trick! Plus sometimes good things happen too: IT Week site | Main | Second Life Big Bang »

Enterprise Architects versus Business Architects

It’s the Open Group Enterprise Architects Practitioners meeting in Austin, Texas, and it’s notable for the fact that they are the group under fire, both from inside the profession and from others outside, and the cause of the fire? SOA of course! The opening speaker Dave Linthicum set the context with the remark; ‘there seem to be two groups of people out there, the world of enterprise architecture and the world of SOA. The funny thing is that those in each world think that they can do the other world’s jobs’. Read his presentation here.

This statement encapsulated the reoccurring theme in many of the sessions, and highlighted the start by the Open Group a year or more ago around effort to get better business languages for expressing requirements. Unfortunately progress isn’t good for just the reason Dave gave, the two sides seem to be struggling to get it together. The Enterprise Architects rightfully see themselves as the responsible keepers of a properly integrated cohesive IT system supporting the business, and the others…?

Well it’s a bit like watching a replay of the data centre manager trying to stop the Networked PC destroying the well managed Computing environment. And of course the ‘others’ in this case won, well at least for a while until it became clear that the incoherency and fragmentation of information was damaging the Enterprise. So does that mean I am totally on the side of the Enterprise Architects? Definitely not, instead I believe that we have to accept that we are facing something new in the business use of technology, just like in the PC era, and have to change our approach to accommodate this. Try the blog by Todd Biske live from the event for comments that are more in line with my thinking.

But I want to go one stage further and question the assumption of it being the role of an Enterprise Architect to create reusable Services. To me there is a crucial stage before this around working out Business reusable Tasks that can then be captured into Services. After all if the business task itself cannot be defined in a reusable way what hope is there of building a reusable technology captured Service? Seems obvious, but not something I heard commented upon once, other than in my own presentation.

It’s for this reason I support the concept of a Business Architect who can work with the Business side in their own language using vertical sector knowledge to identify this, and the optimised business processes. But when it comes to managing the overall Services environment, and orchestrations, then I come back to the rigour of Enterprise Architects. So it is two different groups of people and skills but I am not sure that either of them understands the others world enough to figure out why they both have a role to play.

TrackBacks

TrackBack URL for this entry: http://www.capgemini.com/cgi-bin/blog/mt-tb.cgi/185

Comments

SOA is one flavour of Enterprise Architecture. With SO the need to have a enterprise view of business services from reuse point of view is paramount. And that is where enterprise and business architects, both claim to know better. But one role is better at identification (BA) and the other at implementation (EA).
So does the business-IT divide stay? In this case, if each side believes the other is redundant, both probably know quite a bit (though not enough, maybe) about the other's job. If the two sides were to work together to find what's overlapping and what's not, it will help sort out who's going to do what and where they meet.

One of the interesting challenges on the topic of re usable 'services' is how can you have this at a 'technology' level, if the 'business' task itself is not reusable?

I.e, if a business defination of the task is not defined in a way that makes it reuable then the technology capture of the task as reusable must fail to gain the advantage sought?

Curiously, I've been running into similar issues!

I read "Enterprise Architectureas Strategy" by Jeanne W. Ross, Peter Weill and David C. Robertson on the weekend. It focusses on the business need - but alludes to how this can be translated into the IT architecture.

It seems like there is also a confusion about all the terms out there!

I agree with Andy on the business service reusability. I wonder if the definition and full import of the term 'reusable' is identical for both the business and enterprise architect? Also, is it important to spot 'potential' reusability? A service is very much a service, even if it has only one consumer, known and potential.

I think Niranjan on the right track. Let's remember what you are trying to do here - deliver to the business exactly what is required to allow people to do their job i.e. the right information to the right resource, human or machine, at the right time. Yes there is a divide - business is about work which create processes, delivery is about the system Architecture. So logic says separate business logic from technology driven delivery? The BA controls the former the EA the latter and once the BA has application built the EA has to support and set up for deployment. OK so connection with legacy does require close support from EA to get information etc (and here SOA may help) but remains BA driven. You will note the BA takes role to drive solution build removing the gap with the business. This is the way it is going, as for SOA frankly if it helps sort out legacy mess (like BT) fine but let's not lose the plot just because it is flavour of the moment! Reusability should not be a driver - it is consequence if it makes sense?

its certainly a 'popular' debate at the moment, but thats almost certainly because there has yet to be a satisfactory resolve to the issue.

a couple of colleagues have been working on what they call a thinking language to help Business managers adress some of these issue.

Post a comment

Commenting Policy

Name:
Email Address:
URL:
Remember personal info?
Comments: (you can't use HTML tags for style)
 


Subscribe


Recent Posts


Navigate



Search the blog