IBM comes around, agrees with Microsoft on SOA

By |2007-08-31T11:42:00+00:00August 31st, 2007|Enterprise Architecture|

David Linthicum pointed out this gem from IBM’s Bobby Wolfe that admits, openly, that you cannot buy a product and then, magically, get a SOA out of it.  Hooray!  Microsoft has been trying to tell people for years that SOA is not a product, it is a way of building

The fact that this message is coming from Bobby Wolfe, co-author of the landmark book Enterprise Integration Patterns, is indicative.  Common sense is much more refreshing than marketing noise. 

Wolfe goes on to explain what you get when you buy a product without thinking about SOA:

“The problem is this: An ESB by itself produces no business value. An ESB is a means to an end, not the end itself. An ESB is like the electrical wiring or plumbing of an SOA. Plumbing does not produce value; sinks with water coming out of their faucets do. Wiring does not produce value; lights, especially lights connected to switches, are valuable. A road is not valuable except that it enables you to get from one point to another. An ESB without an SOA is like a road from someplace nobody is located going to other places nobody wants to be. People might eventually want to go to those places, but in the meantime, the road is all cost and no benefit.”

Bobby Wolfe calls this style “ESB-Oriented Architecture,” a term that David Linthicum warns is “not an Architecture.”  To quote David Linthicum:

“The truth seems to finally be coming out…you can’t buy a SOA. Indeed, SOA is something you do, and an ESB is not an architecture, it’s a mere instance of technology.”

I agree with David Linthicum on this.  There is no such animal as ESB-Oriented Architecture.  So while I’m pointing out the strengths of this article, let’s all agree not to create a new term from this one.  If I see a powerpoint with the acronym EOA on it, I’m leaving the room!

SOA never was something you could buy.  You have to change the way you write software to build an Enterprise SOA. 

Building an Enterprise SOA is a very different task from building a single application with a nice web services layer… that you can do without rocking the world, and a lot of folks have done it, but that’s not what I’m alluding to.  I’m convinced that the real payoff comes from building for the Enterprise, and that means understanding your shared, or canonical, data model.  That means understanding your business objects and events.  

Enterprise SOA requires management frameworks to rationalize your portfolio, and process changes to fund your projects in a way that encourages the creation of specific services, a well-run Enterprise Program Management Office (EPMO) for insuring that governance occurs and that quality is high, and a functioning Enterprise Architecture team that allows you to bring the information together, and evangelize it’s use.

Buying an ESB and hoping for a SOA is like going to Home Depot and buying a truckload full of random building supplies, dumping them on an empty lot, and hoping someone will build a house from it. 

You can buy bits of technology, but if you approach this problem with technology first, you will fail.  Bobby Wolfe agrees.

The mindset is often: “We don’t know what else we need, so for now we will just build an ESB.” But is this really any different than the approach of “You start coding, I’ll go find out what they want”?


When they are not ready…

By |2007-08-29T21:47:00+00:00August 29th, 2007|Enterprise Architecture|

Leadership is a funny thing.  You cannot lead someone to where they are not ready to go.  You have to lead them to where they are able to go next.

Blanchard calls this “Situational Leadership.”  It is up to a leader to be able to evaluate where someone is, figure out the steps to get them to a point of excellence, and then help them to take the first step. 

For example, let’s say I want my son to be an accomplished swimmer.  I can say “Dive in and give my a lap with a breast stroke and a lap with a backstroke”.  I can say it… but if he can’t swim for 10 feet in a row, and his breast stroke is more of a flailing thrash, then my request will not produce the desired result.  I will have taught him nothing.  He will be frustrated and resentful.  Nothing positive will occur.

On the other hand, if I ask him to show me where he’s at, and I explain that the next step is to work on his breast stroke, and we are going to take it slow… then both of us feel a lot better and he makes one more step towards becoming an accomplished swimmer.

Why the analogy?  Because the same thing works for teams and departments and organizations.

If you have a team of mainframe CICS developers, good ones, throwing them into a SOA implementation may be a stretch.  Or maybe not.  CICS is really a message-based mechanism, and if that team is used to developing their systems from a message-oriented approach, then you are simply teaching technology, not entirely new concepts.

You have to ask them to show you where they are at.  You have to evaluate, ask questions, find out what they do well.  You have to perform that ‘skills gap analysis’ before you can begin to take a person, a team, an organization down the road.  And then, you can’t ask for the full lap with the breaststroke if that is not what the are able to do. 

Lead from the place where your follower is standing.  You cannot successfully lead from anywhere else.

This is not a technology problem.  This is a human problem.  But in Enterprise Architecture, it is tempting to assume that every technology can be considered, because, of course, “it’s just software and we know software.”  That’s bizarre.  It’s like saying “everyone can do anything.”  To make it worse, if we ask the developers, they will say that bizarre assumption is true, even when it is not.  That really throws the notion of personal accountability out the window, but it is typical of software people. 

Let’s say you need to create a roadmap.  The domain is something small… let’s say property management.  (“Small” in that, for most enterprises, there are not a laundry list of integration points).  Let’s say you, as the architect, have led a process to pick a good commercial package.  You find a nice application.  (We will call it “Propman”).  It has the features your business wants.  It has a secure, reliable, scalable architecture.  It even has web services.   That’s good because your financial system also has a web service interface.  No one uses it yet, but Xavier, one of your team members, keeps telling you that he’s dying to try “doing SOA work.”

Do you propose a roadmap that shows data integration from the “Propman” app to the financial system using web services? 

Maybe.   As long as you have evaluated Xavier and you are absolutely certain that he is up to the challenge.  Odds are, he’s not.  It is more likely that he’s read about SOA in a magazine and he’s eager to try… or he wants to improve his resume and bolt for the door.  Your roadmap is incomplete because the technology is possible, but the people are not ready. 

Architectural roadmaps have to take things into account that extend far beyond technology.  They have to take into account things like corporate culture, technical readiness, local availability of talent, financial implications, deadline implications, strategic directions, company policies and, yes, company politics.  These things will affect your choices.  They must.  You have to lead the organization from where it’s at, not where you wish it was at.

A close advisor told me the other day, “be aware of your radar… keep it turned on.”  Look for all angles that may influence the potential success of your domain roadmap. 

If you look only at the technology, you may miss the fact that the team is not ready to use it. 

And that is one way (of many) that projects end up under water.

Enterprise Architect: Breadth, Depth, and Interchangable Parts

By |2007-08-29T09:56:00+00:00August 29th, 2007|Enterprise Architecture|

Alan Inglis has posted a second time about the need for an Enterprise Architect to be oriented more towards breadth than depth.  I agree but I feel the squeeze.

Enterprise architecture is there to bridge business and IT concerns.  Therefore, they need to be talking to business representatives and business leaders to build trust, listen to strategy, offer insight and ideas, and clarify requirements.  They need to be talking to IT architects and leaders to build rapport, deliver actionable plans, influence, and sometimes, enforce.

As you become more immersed in the EA role, you begin to lose your technical depth.  I haven’t coded significantly in two years now.  There are technologies that I understand but have not coded.  That is good (to a point) and bad (to a point). 

If our industry were more mature or if the rate of change was more moderate, I would not need to code to keep up.  But it isn’t.  Our industry is changing daily, and there is no widely available model to allow an architect to understand a new technology quickly without experiencing it directly.  There is no standard parts mechanism that drives people there, and therefore, no economic incentive for vendors to publish their products with model elements that would allow an architect to make direct comparisons in any kind of depth.  Marketecture rules.

And therefore, the Enterprise Architect is limited.  We can never get far from the level of technical depth required to deliver decisive insight, yet that heavy burden of constant learning prevents us from being able to reach up to a higher level of business effectiveness.  The fact that we are a hybrid means that we can neither job terribly well. 

And that, I think, is long term, the biggest reason why we are not often enough seen as valuable.  Both sides (Business and IT) can produce someone who knows their side better and deeper than the EA.  In a cooperative environment, it won’t matter.  But in many IT shops, there’s not enough cooperation to butter one side of a piece of toast.

There is a way out, but it is long term.  We need to get a consistent taxonomy of systems and features, make it available, have the vendor community contribute to the definition of it, and then provide incentive for them to map their own commercial systems to it.  Then architects can make the comparisons they need to make without needing a direct and deep engagement with every new technology. 

That’s the transition to interchangable parts.  That won’t be easy.

Leadership vs. Management

By |2007-08-28T02:34:00+00:00August 28th, 2007|Enterprise Architecture|

It is often said that if you are in a group of explorers hacking through a thick jungle, the manager is worried about cutting a straight and efficient path, while the leader is climbing the trees to make sure that you are goin in the right direction.  Fact is, you need both.

When I describe architecture, sometimes I need to lead.  Sometimes it is about insuring that the direction is the right one.  I need to make sure that we are keeping the correct things visible as the goal, and staying focused on the elements that will get us there, while staying tuned to the “snares” that would prevent progress.

Other times, I need to manage.  I need to write the document, create the diagram, lead the team meeting, enter rows in the schedule.  It’s day to day, block and tackle stuff.  It’s taking my turn at point.  It is not creative, but it is necessary.

This distinction applies whether you have direct reports, or you are in a position of influence (as I am these days).  The rules really aren’t different, even though the balance of motivations are. 

The toughest part, really, is knowing when to lead and when to manage. 

I have no real ‘formula’.  I will say this: normally your team will tell you.  The key is to listen.

Your team will tell you if they feel blocked, or confused, or if they have flipped the bozo bit on someone.  They will tell you if they need help… if you know how to listen. 

Listening is an art.  It means not only hearing status reports (or excuses), but digging deeper to understand priority conflicts or to detect gaps in tools, abilities, or confidence.  It means knowing when to express support and when to offer alternatives.  It requires patience, insistence, and, as often as not, silence.  Listening means going beyond the “what” to get to the “why,” and then to push to the “why not?” 

I spent a few years as a manager.  I’m no grand expert.  I will say this: to decide whether you need to lead or to manage, the key is to listen.  

Actionable Enterprise Architecture through Feedback

By |2007-08-27T04:05:00+00:00August 27th, 2007|Enterprise Architecture|

This is my third post on Feedback loops and EA.

At the Gartner EA Summit in the spring, I was chatting with some folks at lunch, and the question came up: what’s the biggest criticism of EA in your organization… and the answer was nearly unanimous: “your models are great, but we can’t really use them when building systems.”  In other words, EA is not actionable.

 I’ve been thinking about this one a lot.  As I build out the Integration area, I’m trying to avoid the stain of “non-actionable EA” by directly engaging with the project teams.  But direct engagement isn’t enough.  There has to be a feedback loop.

Traditionally, EA teams will go off and create a set of models that describe how the world should look.  There may be some strategy in there, as well as some wishful thinking.  When the project teams get going, we hand them our work and say: here’s your shiny solution!  They thank the EA politely and then get around to building an app that doesn’t take the EA models into account at all.

The IT teams get no value out of EA. 

This engagement model has to change.  The IT teams have to have skin in the game.  The good men and women building our systems need to feel ownership of the EA models.  They need to feel like those models represent their interests, and carry their career forward.  They need to be incented and rewarded through the connection with EA models.

Today, in many organizations, including my own, this rarely happens.

I can see the need for a number of feedback loops:

1) Models.  The first loop needs to take models into account.  When the EA team comes in with a model and the IT team ignores it, it was not valuable.  If the IT team comes in with a model and the EA team ignores it, same thing.  Both behaviors must change.  But if both sides keep pointing fingers saying “that guy has to change first” then we are no better than schoolkids fighting in a playground.  Someone has to be the first to own up.  I believe it should be the EA team that starts by accepting feedback from the IT teams.  That starts with models. We need to take our models, compare them to the models of the IT teams, and where they differ, we need to work with the IT teams to figure out what needs to change… in the EA model.   This includes data models, reference architectures, and taxonomies.

What parts of their design really are “enterprise?”  I doubt anyone asked most IT teams that question, and they get to try to answer.  With a few rounds, we can create a good answer, and I’ll bet that the part we agree on, will be the most stable part of the design.  The IT team will buy in.

2) Participation.  The second loop is one in which we measure the relevance of our communication processes by looking at how each team participates with the other teams.  Who comes to one another’s meetings?  What ideas are shared?  What decisions are made?  In order to develop a feedback loop, folks have to actually speak with one another.  They need to participate in the success of one anothers’ projects.  This participation builds trust and connects the most important, and the most difficult, type of integration: between people.  This kind of peer-to-peer feedback crosses in many directions.  not just EA <–> Solution Arch, but also Solution Arch <–> Solution Arch. 

3) Incentives.  Once a year, in our organization, every employee comes before their manager for a performance review.  The process is fairly involved, and there is a lot at stake.  In Microsoft, stock awards and cash bonuses ride on the results of your performance review, and employees will work very hard to make sure that their review looks as good as possible.  If part of that review process includes being rewarded for participation, involvement, and consumption of models from other teams, then the behavior will occur more frequently.  Of course, and organization can tie itself into knots if EVERYONE is supposed to reach out to someone else before getting anything done.  Striking that kind of balance is difficult, but not impossible.  Regardless of difficulty on the management side, getting incentives in place to encourage the right amount of cross-team collaboration will go a long way towards creating the kind of interdependency that is necessary to make Enterprise Architecture actionable.

At the end of the day, Enterprise Architecture is not a team or a set of models.  It is a system of interacting variables, people, incentives, and relationships.  We all have to believe that the goal is worth pursuing, and our management has to support us in pursuing it. 

With feedback, EA can become actionable.  Without it, I cannot see it happening.  EA is a culture shift.  Until folks make the shift, EA folks are going to struggle with the bars of the ivory tower where their organization locks them away.

Agility, Feedback, and Enterprise Architecture

By |2007-08-26T10:49:22+00:00August 26th, 2007|Enterprise Architecture|

I blogged a few days back about agility in EA: Deliver Early, Deliver Often, Take Feedback, Iterate. 

I’ve said often that this concept is just as applicable in business as it is in technology. 

Enterprise Architecture is supposed to be the bridge between business and technology.  Let’s think about the concept of a bridge for a minute: we take changes on one side and translate them into changes on another. 

Can that work both ways?  Most of the time, the descriptions are one way: we take changes in business and translate them to technology, but I believe that we lose value if we Don’t take changes in technology and translate them to the business.

That’s an easy thing to say, because there are two definitions of ‘technology.’  If we talk in generalities (technology trends, new capabilities, new threats, new opportunities), then taking technology to the business is the job of IT and the CIO anyway.  That is very important, but not what I’m getting at.

There are innovations that occur deep in the bowels of IT that stay there.  They never come back to be visited, or understood, or reused, or leveraged, in the business.  That is because the business, in general, has no way to get that feedback.

An example would be good.

For a while at Microsoft, I worked with the Legal IT division.  Their charter: provide tools to the lawyers and paralegals in the corporate law department.  They had tools for discovery and document management and workflow… but no tools for clause management.

Clause management allows attorneys to compose legal documents from pre-written ‘template’ clauses.  With a clause management tool, you create a workflow that creates these clauses, and you can update them in all downstream document templates by updating them in the clause management tool.  No more situations where a contract is signed using ‘old’ clauses when ‘new’ ones should be used.

Clause management is something that attorneys want, but never get around to paying for. 

That said, as I moved into Enterprise Architecture and started looking at tools used by other parts of the Microsoft business, I found three clause management tools.  Not one of them was written by the legal IT team.  Most of the attorneys had no access to them.  They were used by the business teams to keep track of the clauses that the attorneys had approved so that a new contract could be created quickly.

In Enterprise Architecture, we want to be able to tell the Legal department that a team, in the company, wants to build a clause management tool.  Not only can they vet the requirements, but we can make sure that the resulting tool would be useful to the attorneys for many other businesses.  In other words, actually connect the tools to the users who should be using them, not just the ones who are paying for them.

And this is one place where Enterprise Architecture can help.  By mapping the features of a new system to a consistent framework that we call ‘Solution Domains,’ the Enterprise Architecture team is able to draw attention to the fact that a new project (or an existing app) meets needs in many areas.  We can see overlaps before they happen, and overlaps that already exist.  We can get the right constituents into the room and make sure that the correct voices are heard.

This is a form of ‘feedback’ in the same agile sense.   Our customer is the enterprise.  It is an odd organism… completely capable of performing excellent work in one area, that another area is oblivious to.  When the enterprise asks, Enterprise Architecture needs to be there to bring people together, get the innovations surfaced, and develop tools that everyone can use.

Business Case for Integration, part two

By |2007-08-24T16:17:00+00:00August 24th, 2007|Enterprise Architecture|

My good friend Harry Pierson took a pass at my ‘business case for integration’ post the other day on his blog.  He ended up shortening my list of integration benefits from four benefits to one.  For the record: I agree that he picked the correct benefit as being important.

I will take the list items from the prior post, break them out, and look at Harry’s concerns one at a time.  Harry’s response is both visceral and useful.  If an intelligent and thoughtful (albeit noisy) guy like Harry came away from that list with misunderstandings, that means that I need to polish the list. 

When communicating, it is the responsibility of the speaker to insure that the actual message is heard.  Words are the medium.  If the message is not being heard, the words must change.  Harry is not wrong to shoot down my words if I failed to express my message correctly.

The List

Keep in mind that these elements are expressed in terms of “what will change if we integrate well.” 

1. We have better business intelligence.  We have better understanding of our customers, our partners, our products, and our business.  And from that understanding, we make better decisions.  Those decisions are made in a federated manner using self-apparent information.

We agree on this one.  Let’s jump to the next one.

2. We have end-to-end business processes that cross multiple systems, multiple roles, multiple geographies, and multiple data stores, all aware of and supporting the needs of the customer. [original text]

Harry points out the lack of clarity in this statement.  The business has processes that cross systems, and they care primarily if those processes are efficient and well coordinated.  They don’t care about the systems and data stores.  However, the processes we have are NOT all “supporting the needs of the customer.”  We are not there yet.

He completely missed that point, and therefore threw out the baby with the bathwater when he chucked this one.  So to clarify, I will change the text on this one and I’ll add another sentence to clarify the process change part.

2. We have end-to-end business processes that seamlessly cross multiple touch-points, multiple roles, and multiple geographies, all supporting the needs of the customer. Those processes can change readily and inexpensively as strategy and customer needs change.

The business value is that integration allows the creation of altogether new processes, ones that can adapt and change and be laser-focused on meeting the needs of the customer without incurring massive IT costs.  Most enterprises struggle with this, and ours is no exception. 

Next point:

3. We have end-to-end awareness of the metrics that drive both dissatisfaction and cost, and we can take that knowledge and apply it to making our business better. [original text]

The intent was to include the concept of “process metrics,” which is often not included in traditional business intelligence scope.  I could have expressed this more clearly.  Business intelligence is typically focused on the metrics with respect to sales, regions, customers, segments, products, etc.  Some very well-oiled companies include process metrics in their BI infrastructure, but not all, because many organizations simply don’t collect this data in an automated fashion. 

So, to clarify this one as well.

3. We have end-to-end awareness of process efficiency through the automatic collection of process metrics.  Using this data, we will be able to address the causes of customer dissatisfaction and operational cost.

If our systems are truly well integrated, it will be simpler to collect and report on process metrics and therefore feed efforts at process improvement.

The fourth one is interesting. 

4. We have a more efficient enterprise, more able to grow to a larger size, at an accelerated rate, and still respond with agility to changing business opportunities.

Harry doesn’t have any problem with the text… he simply says that the business doesn’t care.  Interesting.  Without divulging the nitty-gritty details, I will say this: If we add up the dollars, I’d be willing to bet a nice lunch that Microsoft has spent more money, in the past four years, on improving operational efficiency than we have on business intelligence. 

Because a lack of efficiency creates pain, and business spends to remove pain. 

So I don’t have to change this one.  I stand by it. 

Harry is right about one thing: we don’t sell Integration to the business, any more than we sell SOA to the business.  But we do need to make sure that the IT leaders understand and support the amount of effort that will go into integration.  That is not ‘sales’ because there is no ‘purchase’ process.  The benefit I’m looking for is leadership support, not a funded project.

Is it time to bring the FEA concepts to the commercial space?

By |2007-08-24T12:13:00+00:00August 24th, 2007|Enterprise Architecture|

For years, we’ve been living with Zachmann and now TOGAF as commercially available EA frameworks, but honestly, they don’t address the problems faced by large organziations with respect to complexity.

The Federal Enterprise Architecture does.  That’s because of a few things that the Federal Government has that we (in the commercial sector) don’t:

1) Scale.  The US Federal Government is a model for a very large and distributed organization.  Different agencies have completely different reasons to exist.  They are like independent businesses.  That size and mission has the same effect on their computing infrastructure as you’d expect for a corporation: lots of duplication, incompatible data models, and a mess of integration challenges.  They face the worst, so any model that works there can be pared down to work anywhere else.

2) Stability of Vision.  Face it, most organizations, when trying to develop their Enterprise Architectures, gave up way too soon to see benefits.  The US Federal Government doesn’t operate the same way.  While businesses think about the next quarter and the next year, Congress thinks about the next decade and the next century.  In order to provide consistency over long periods, legislation is a good tool.  Corporations DON’T WRITE DOWN things akin to legislation, and as a result, there is no consistent reason to keep doing things that will help in five years, but won’t help now.  As a result, the feds have a consistency of vision that is enviable in the field of Enterprise Architecture.

3) Public openness.  We paid for it.  We own it.  There is no reason, nor rationale, to create the FEA behind a closed door.  And therefore, we can all learn from it, and use it, and adapt it.  It’s the ultimate Open Source Enterprise Architecture.

To be honest, we needed someone with that long view to start, run, and keep running.  The Office of Management and Budget is that someone, and their Federal Enterprise Architecture is a very good Version 2.0 of what Enterprise Architecture should look like.  It took 12 years to get to this point.  Perhaps a commercial organization would have gotten here quicker… if they could stick to something for more than a year at a time. 

I think it is time to translate the FEA to the commercial sector, make it fit within current management models for commercial space, and knock off Zachmann once and for all.  ZF was a great start, but it doesn’t work for what we need it to do: control complexity.  The FEA does. 

Judge for yourself.  Look, with open minds, at the FEA.  http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html


Agile Enterprise Architecture

By |2007-08-23T09:32:00+00:00August 23rd, 2007|Enterprise Architecture|

One of the things I’ve learned from Agile methods: Deliver Early, Deliver Often, Take Feedback, Iterate.

When you do, your perception of value goes up, and you build trust with the customer, especially if they are not sure you are doing what they want done. 

Building an Enterprise Architecture, in a company that is not used to having an Enterprise Architecture, can sometimes be frustrating.  Our team is constantly fighting the battle to be relevant, engaged, ‘actionable’ and yet still high-level enough to span the enterprise.

My one bit of advice, for any level of EA, comes from Agile methods: Deliver Early, Deliver Often, Take Feedback, and Iterate.

It is all too tempting to do the ‘waterfall’ thing: take a long time, deliver something you think is cool, and spend years selling it to people who don’t care.  I’ve heard many stories told of that model.  We avoid that by being Agile.

The Business Case For Integrated Systems

By |2007-08-22T03:24:00+00:00August 22nd, 2007|Enterprise Architecture|

I’ve been looking at the ‘business case for integration.’  How odd does that sound? 

If I’m going to be able to sell the idea that ‘integration is a good thing to spend our time on,’ then I need to know both WHY we would want integration, and IN WHAT SITUATIONS would I expect integration to produce a benefit.  In short, the business case. 

This is my second attempt.  My first attempt was a partial success.  I created a notion of the business processes (in general) driving the need for integration across systems, but honestly, it didn’t click.  I couldn’t find an approach that made sense.  Nothing that an executive sponsor would be able to understand, much less agree with.  Then, I looked at the problem from a different angle.

“Begin with the end in mind.” 

(Obvious, I know, but I will admit to you, gentle reader, that sometimes the obvious only appears that way after you’ve recognized it.  Until that time, it was not obvious.  After that point in time, it was common sense.  Case in point: why did it take so long to put wheels on luggage?)

If I’m going to ‘begin with the end in mind,’ then I need to ask a simple question.  Assume we succeeded, and our systems are all optimally integrated.  What has changed? 

  1. We have better business intelligence.  We have better understanding of our customers, our partners, our products, and our business.  And from that understanding, we make better decisions.  Those decisions are made in a federated manner using self-apparent information.
  2. We have end-to-end business processes that cross multiple systems, multiple roles, multiple geographies, and multiple data stores, all aware of and supporting the needs of the customer.
  3. We have end-to-end awareness of the metrics that drive both dissatisfaction and cost, and we can take that knowledge and apply it to making our business better.
  4. We have a more efficient enterprise, more able to grow to a larger size, at an accelerated rate, and still respond with agility to changing business opportunities.

That’s it.  The big four.  Those are the shining lights that drive the vision for integration. 

With integration, we create the foundation for a business that is Smarter, more Comprehensive, more Self Aware, and more Efficient. 

SOA is a tool for integration.  So is Master Data Management.  So is Enterprise Information Management.  We are all reaching for the same goal. 

My business case for SOA is not a business case for SOA.  (I don’t believe in selling SOA to the business and more than I believe in selling C# to the business.)  Nope: I don’t care to talk about SOA.  I want to talk about the problems that we can address through integration.  I want to share the benefits outlined above.

Integration will let the business grow larger, run smoother, make better decisions, and improve upon itself.  Who can say “no” to that?