« Open Group Conference | Main | SOA for Dummies »
July 24, 2007SOA and Enterprise Architecture
Spending the day at the Open Group’s Enterprise Architecture Practitioners Conference got me thinking about what is needed to move forward with SOA. The first day of the conference focused on SOA. The Open Group’s goal is to raise the level of professional standards by creating an education and certification process for enterprise architects. The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) includes a Business Architecture, Information Systems Architecture (which includes Data Architecture and Applications Architecture) and Technology Architecture. These architecture disciplines are pretty standard – we included them in the architecture framework we created at DeBoever Architectures which got sold to Meta Group which got sold to Gartner Group.
However, when it comes to SOA and distributed systems, the knowledge and methods involved in each of these architecture disciplines need to be very specialized and are probably performed by different people. For example, business analysts often are responsible for the Business Architecture and the methods to do this include process modeling. Data Architecture needs to include semantic integration. Data architects should be responsible for creating the canonical enterprise data model, mapping semantic meaning of information across systems, and defining information services that are used by application architects. They are not creating the business architecture – they are elbow deep in data.
SOA Application Architects need to create the business services that support the business architecture in a flexible way. They need to understand how create reusable services, including decomposing business services into intermediary services which aggregate information from multiple systems, as well as defining resource level services which can be flexibly combined into business level services. They should be able to use data services, not have to create them (they have enough to do without understanding the bits and bytes within the back end systems).
SOA Technical Architecture focuses on standardizing on technical infrastructure services that need to support the business applications. This is a very different set of knowledge and experience than Data Architects and Application Architects need to have. In this view of things, and “Enterprise Architect” would have a knowledge of each of these areas but is probably not responsible for executing all (unless it’s a small company – and small companies don’t generally have enterprise architects). The “Enterprise Architect” needs to know how all of these inter-relate, and establish the architecture governance policies and procedures.
Dave Linthicum’s statement that SOA as a term will go away in 5 years and be subsumed by enterprise architecture sparked quite a bit of discussion. I don’t think that time frame is remotely possible given the current state of SOA maturity and adoption. Few companies have business level services and they don’t know how to build them. I spoke with several attendees who told me this was a major challenge. They have not found a way to guide developers to build services based on business requirements (as opposed to slapping WSDL interfaces on every IT component).
(Listen to a short interview with a conference attendee).
In fact, few of the organizations I have spoken with actually have business services deployed. One large government agency I spoke with, which claimed they were far down the SOA road with 250 deployed services, only had data access level services (CRUD level services) – no business services. A large manufacturer I spoke with claimed they had a mature SOA implementation and were saving millings of dollars. But they actually only had IT infrastructure services (yes, you can get benefit from and IT only based SOA).
But if organizations are adopting SOA to achieve business agility, which is what all the surveys are indicating, then the only way to achieve this is to develop a business service architecture. This requires training Business Architects, Information Architects (I want to say the job is bigger than just data – there’s more here), and Application Architects, who all need to work together along with the Technical Architects.
The certified Enterprise Architect being certified in TOGAF is by necessity a generalist. It is important to have someone understand the complete landscape, but this one person can not be an expert in all aspects of the architecture. In fast, the most important skills this person needs are probably people skills, and the ability to communicate and partner with the business.
Five years to accomplish all this? Do not think that’s likely. What architecture path are you following?
Posted by bethgb at 03:53 PM in
SOA
|
Digg This |
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/2156


SOA - Integration Industry Pulse
