1
Last month an interesting study about SOA implementation success rates was released:
The Burton Group SOA Study
It states that fully 50% of the projects assessed were considered a complete failure and 30% more seriously underperformed. That leaves only a 20% success rate - this track record is nothing less than dismal. Why is this still happening? Why is SOA so difficult to realize?
Well, rather than writing a dissertation, let's address the root causes with a top ten list:
1.
There is still no widely agreed upon set of best practices for SOA implementation (or for that matter even an industry standard definition for what SOA is and isn't).
2.
The confusion regarding SOA and web services is still pervasive; technically you can have SOA without any web services being developed per if the architectural principles are met.
3.
SOA is not application-centric, despite appearances to the contrary. SOA is the first and only comprehensive development paradigm that is wholly integration-centric. (it combines the previous middle-ware integration capabilities with
OO and web-centric logic).
4.
Most SOA architects don't have a clue about 75% of what a true enterprise integration requires. Solution integrators tend to hire former J2EE / web services developers and assume that they will magically grasp the intricacies of
System of Systems enterprises magically from the giant wisdom cloud in the middle of so many diagrams. NOT...
5.
SOA without the enterprise data layer isn't going anywhere, fast.
6.
COTs driven SOA is inherently risky, as the recent merger between two of the four leading vendors has proven (Oracle buying BEA). How many people are now having to reassess their infrastructure as a result?
7.
Deploying a SOA stack in itself that doesn't actually do anything is an intellectual exercise to be sure, but also a complete waste of time and money.
8.
SOA is dynamic, or at least it's supposed to be and more importantly it is not our first foray into managing dynamic environments, so why does the industry seem to have collective amnesia in this regard? Systems engineers have been doing what SOA developers are failing to do now for twenty years, yet you'll never see a member of that rare species on most SOA projects.
9.
Developers rule - NOT. Design also drives development not the other way around, we wouldn't want the drywall guy designing a skyscraper, yet that happens in SOA implementations (figuratively speaking). Some people call this model-driven
SOA, however it was the way SOA was always supposed to be conducted. You can't really do "Agile SOA" in the strictest sense of the Agile philosophy given SOA's integration implications - the big picture has to be understood up front.

10.
The standards and hype don't drive the solutions, the business does - if we remember that we can avoid some obvious traps. Hype doesn't solve problems or deliver capability and the standards that are applied are the ones that make sense, not merely the ones everyone says ought to be applied in a perfect world.
2

3

4
SOA is a complex topic - it covers more than just application architecture, more than governance, more than the SOA product stacks - it essentially represents a new way to view Information Technology capability development and support. First and foremost, Services Oriented Architecture is a design paradigm, but one that must also support runtime performance engineering. Many view SOA as the cornerstone or foundation for complete transformation of their IT environments, and while it isn't primarily designed to support that, we've added to SOA where necessary in order to help organizations utilize it as a 'Transformation agent' and a foundation for holisitc enterprise management.

5
This is one example of how we manage the (SOA) service inventory discovery process in lockstep with Legacy Migration...
We understand that the most important aspect of SOA is how it applies to your enterprise, and how it might solve your problems. No two SOA solutions are exactly alike - our consulting experts will help you determine what's needed and when. The right way to introduce change and achieve transformation is the way that will work best for your environment - and that's something we can help you understand and realize.
In many ways, SOA is much like enterprise integration - it comprises a number of different but related skills, activities and technologies. Our service offering recognizes that fact and the following list of SOA Capabilities and Deliverables will help you understand exactly what we can to help you make
SOA a success in your organization. Not every engagement requires all of these capabilities or deliverables - the precise mix of activities and output is assessed on a per project basis.










SOA Strategy
SOA Infrastructure Design
SOA Cost Estimation
SOA Requirements Engineering
SOA Inventory Design
SOA Outreach
SOA Application Design
SOA Data Layer / Tier Design
SOA EA Reconciliation
SOA + MDM Design










SOA Roadmaps & Conops
Datacenter Design & Configuration artifacts
WBS, Business Case
Automated Requirements Solution
Blueprints, SOA Patterns
Web 2.0 Portal [wikis, blogs etc.]
UML & other design notation
ERD & other design notation
Semantic Mapping across Artifacts
Metadata design & solution configuration

6












SOA Governance Rulesets
SOA Business Design - BPMN
SOA Business Logic - BPEL
Semantic Modeling
Community of Interest (COI) Management
Federation Design (Data, ESB, Enclaves)
SOA Performance Engineering
Enterprise Service Bus (ESB)
SOA Contract & SLA Development
Legacy Migration Planning
Legacy + SOA Integration or Wrapping
Software as a Service SaaS Design and Integration 











Contracts, WS-Policy, WSDLs, Rules Engine
BPMN artifacts in various tools
BPEL Logic in various tools
OWL, RDF
Data Dictionaries, charters, wikis
Design configuration
Design documentation & test plans
Assessments, design specifications
Reports, XML output
Reports, requirements, designs, testing
Reports, requirements, designs, testing
Reports, requirements, designs, testing
17 January 2009 - by Sharon Evans
Very few people that actually use enterprise architecture metrics as they feel architecture is just subjective and not measureable.  If you are an Enterprise Architect in an organization who is in “run and build” mode, rather than planning mode with your enterprise architecture, this is critical information for you.
Benefit’s and architecture metrics are both difficult to quantify but not impossible. That is that’s the message that
I want to leave you with today. Part of the benefits of using metrics and building them into your EA programs is that this is what’s going to build credibility for you.
One of the questions I’m asked most is how do I sell architecture to executives and to the rest of my organization. When you sell to them, if you happen to be good enough at selling, and you are able to get a program started — the real key part of that program is maintaining credibility. Enterprise Architecture Metrics is the way you are going to maintain credibility. It’s also the very best method to measure and communicate your successes.

7
Organizations that actually have mature actionable architectures architectures they use to run their organization on a day-to-day basis with and get the best use of, all include metrics. So that is one of the keys that has to be in your tool bag if you want to succeed in this area. What are they? Architecture Metrics are a means of aligning the business goals with the experience and performance that you achieved from the architecture. They are a means of communicating the value back to the stakeholders.
These are the people that have given you your goals to start with. They also can be quantifiable and very often qualitative. There are means of actually getting the key information back to the people who need to use it to both build maturity within your models and within your programs as well as to run the IT infrastructure.
These are methods and ways of depicting data that is collected in order to measure both the effectiveness and the efficiencies of your organization and your program. There are some resources on the site to help you pick and choose which metrics work for you and your organization.
It’s a comprehensive list and actually a spreadsheet that you can use to slice and dice and tune a set of metrics customized for your organization. The beauty is that metrics can be categorized and discussed and planned in various dimensions and there are different ways to do it. My preferred method is to create a high level dimension check sheet or checklist my your planning.
So you want enterprise architecture metrics and here some different categories in which I would explore. Metrics is all about picking and choosing what is applicable to your organization. What are your goals? So you want to measure the things that match organizational goals for and the things that are important to you and your goals for your Enterprise Architecture Program.
I would also suggest you pick a good blend of tangible and intangible. At the very beginning you’re going to want to collect the things that are tangible because the people are asking you for numbers are number oriented. The things that the business is interested in typically related related to cost, performance and time.
There are also going to be some intangibles and typically the ones that apply to your enterprise architecture program and its success are intangible. When you grow in EA maturity, you’ll find that it’s going to be a balance between the tangible and intangible.
The usual suspects…so these are typical very first things that either come to your mind or are talked about whenever people talk about metrics. And there are conflicting forces here.

8
There are two different sides of the house when it comes to talking about enterprise architecture metrics. And the one side are the ones that you need in order to satisfy the business. Those are the metrics on the left side of the diagram — typically quality, cost, time, performance. Metrics that relate to these business measures are the things that the business are really interested in.
Well you, as the architect or the CIO or the manager of IT, you are interested in other things. You are interested in both sides of the house. How well is this doing for my business and you also want to know things about your architecture program and how well they are meeting your needs as an IT planning tool. Depending on the architecture framework you have selected, you’ll find different metrics more appropriate for measuring your enterprise architecture.
I chose a very basic neutral framework with the basic domain architectures – also the way I categorize enterprise architecture metrics. The acronym here is (BOAIT) – business, organization, application, information and technology. And of course at the very top of the house…while we talk about the architecture house. Those are the metric types that apply right across the enterprise architecture program.

9
This diagram is intended to depict the different categories of metrics are going to apply to one or more of the vertical dimensions or framework domains.
Some examples are:



Business – business performance, sales, costs, time to market, etc.

Organization or operations
Applications or Solutions – average annual system, maintenance and enhancement cost, processing volume by system, interfaces, reports, and numbers of reusable objects
Information – number of databases, by dept, function & location, number of records, tables, pages, links, reorganization time, license costs, etc.
 Technology – hardware, communications, license and maintenance costs, upgrade time, facility cost, etc.
More on enterprise architecture metrics in a future article.