Real World SOA | David Linthicum | January 2008

MORE ENTRIES

January 2008

January 29, 2008 | Comments: (0)

Notes from the Open Group’s 17th Enterprise Architecture Practitioners Conference

I did the keynote yesterday at the Open Group conference held in San Francisco. The conference was well attended, as usual for Open Group events, and also as usual very talented enterprise architects made up the audience.

I went for a different angle this time, for this keynote. I focused first on the business case for SOA and selling SOA, then moving on to the steps for working through a SOA project (SOA Lifecycle). In the past I discussed ROI and the business case for SOA more in passing. Also, I attempted to provide some clear and detailed guidance as to how you create a business case for SOA, size a SOA project, and an overview of the SOA lifecycle. In other words, the fundamentals.

I think it was well received, at least from the comments from those attending.

I'll provide excerpts from my presentation next week on the Podcast. So, make sure you're subscribing to that.

Of course the bloggers are quick to post their views. Here are a few:

From Joe McKendrick's blog.

"Too many times, we're engaging in SOA for SOA's sake. In a keynote that helped kick of the conference, David Linthicum said there are many situations were SOA may simply not be necessary. A mainframe system that rapidly processes transactions may be well enough left alone. "You're not going to increase the speed of your systems by putting a layer on top of it," he said. "SOA success means applying SOA where needed. But if it ain't broke, don't fix it.'"

Companies should pull the plug on SOA efforts not delivering ROI, David said. He also repeated his prediction from a few months back that that SOA would eventually fold into Enterprise Architecture. It only makes sense, he said — companies are discovering that they can't have two separate processes — 'SOA is EA and EA is SOA.'"

From Mike Walkers blog.

"Dave suggests to start with ROI first rather than architecture. I think that this is easier said then done, but I agree at a high level. I do agree that this should happen but as many architects know we are hindered by technology / strict business requirements, cost and deadlines.

Start the Business case right away! Yes, yes yes!!! Ideally focus first on the capability and then figure out the downstream processes you want to enable to build that business case.

Dave asserts that 'the business' is not happy with IT. I agree and this is a perception that we need to change.

Dave provides a simple cost calculator and suggests us to use our own if we have one

He also talks indirectly about the importance of Application Portfolio Mgmt, but doesn't directly call it out. Rather he speaks of the value of having a catalog of SOA assets that provide iterative value

BTW - I love the quotes:

'Managing SOA by Magazine' - Referring to what I lovingly call E-Weeker's that take the guidance from the trade publications to heart and build systems accordingly.

'Vendor Driven Architecture' - Organizations that have bought into one SOA stack and allows that vendor to drive their SOA strategy rather than their business concerns."

He has a lot more detail, so you should click over to his blog and check it out.

From Tony Baer's blog.

"Maybe it's time to go back to basics, advised ZapThink's David Linthicum during his keynote before the Open Group's Enterprise Architects Practitioners Conference, being held this week in San Francisco. With undercurrents as to whether threats of an oncoming recession are taking its toll on SOA budgets, or whether there is what Gartner terms a "trough of disillusionment" afflicting SOA adoption, Linthicum stated to a room of enterprise architects that you have to start with an ROI case."

"But he raised an interesting point on how to quantify ROI from flexibility or agility, which is to compare a scenario of how the business acted previously vs. a predicted scenario after implementation, such as ability to swap out a business service rapidly. A "hard' ROI would come from savings of time – how much would it take to make the change with and without SOA. We don't blame him for not touching the "soft" benefits, such as ability to respond or change course sooner."

"Yet in the next breath, Linthicum stated that it's advisable to take an iterative approach that blends principles of Agile Development in something he terms "Agile SOA." Namely, you develop the vision, but not all the details in advance, and then you advance into it, one modest piece at a time so you don't end up with, what Joe McKendrick termed a couple years ago, "Just a Bunch Of Web Services" or JBOWS."

And, from Jim Phelps.

"Dysfunctional architectures that are currently deployed have led to enterprise that are locked up and unable to really improve because of the complexity. The activities have all be driven by tactical needs not strategic needs.

Enterprise Architecture are raising their hands and saying we need a 'master city plan' but they don't get the budgets or support so they end up acting tactically also.

Need to convince people that the SOA technology and strategic planning are important. Need to start with the business case. The business drivers: Reduction of integration expense, increase in reuse, greater visibility, business empowerment and increase in business agility.

'Think big, start small, succeed often'."

Good to know people are listening.

Posted by Dave Linthicum on January 29, 2008 06:34 AM

January 29, 2008 | Comments: (0)

Doing SOA Right

Download file

Posted by Dave Linthicum on January 29, 2008 05:42 AM

January 26, 2008 | Comments: (0)

When do you Cancel a SOA Project?

What? Linthicum is talking about canceling SOA? How can this be?

As we discussed in previous blogs around defending SOA during budget cuts, there are indeed instances when a SOA project should be shut down in the interest of the business. This does not mean that SOA is bad, nor enterprise architecture, only that sometimes people do SOA for the wrong reasons, and there is no clear benefit.

Many SOA projects are created out of hype, not need. Clearly many enterprises are "managing by magazine" and are more concerned about the doing something cool rather than doing something helpful. You know the difference, and I'm sure there are both types of projects in your organization today.

So, should you cancel a SOA project? Here are some tests:

First, no strategic vision around how that projects fits in the overall enterprise architecture. This is the big one. If there is no roadmap, no plan, no vision, you're off to a false start. Better stop, do some planning inclusive of understanding the business, then restart later. Typically this means the first project was moving in the wrong direction…what you get when taking a shot in the dark.

Second, it's not SOA. Many projects are called SOA, but are really not SOA. Often I see portal development projects that are funded with the title "SOA" but have nothing to do with services, agility, reuse, or architecture, they are just portal development projects. Portals are great, and valuable to the business, but they are not SOA unless part of a larger plan and strategy. It's architecture, at the end of the day.

Finally, not enough resources. Many SOA projects are under funded, typically because they are considered strategic and long term, with more resources directed at short term and tactical. I would rather cancel the project and start again later, than have a lot of well intentioned people break their picks on making changes to the architecture that will have any value.

Hopefully you're not working on a SOA project that needs to have the plug pulled, but if you are you may have some tough calls to make.

Posted by Dave Linthicum on January 26, 2008 05:03 PM

January 24, 2008 | Comments: (0)

Once Again…Setting the Record Straight

Dan Foody took me to task as a "flip flopper" in his recent post.

"It's only two months ago that Dave Linthicum gave me a lot of flack when I criticized his statement to (and I quote) 'resist the temptation to redirect resources toward tactical business needs.'

However, recently Dave changed his tune when he said, "the best approach is to focus on short term objectives that are directly related to the generation of revenue.' Dave, it's good to see you're listening... even though it took a while :-)"

No Dan, I'm not agreeing with you. As I've always stated you need to prove the value of the strategy with short term wins, however the objective is always to support the long term strategy. I think I've written about that enough times not to have to say it again. When people take me out of context like this I know how the presidential candidates feel.

Here is the complete quote:

"SOA always needs to prove its value and during times of economic uncertainly, where capital budgets are contracting, the best approach is to focus on short term objectives that are directly related to the generation or revenue. This does not replace a long term SOA strategy, which is very important, it's just a way to provide leadership with proof points to justify the continued investment. Perhaps the service enablement of the existing legacy systems to provide better interfaces for trading partners or the ability to abstract processes/services into configurable domains, thus allowing processes to change without a great deal of latency and cost."

The issue I had was that many view SOA as a project, or a set of disconnected projects. It's really more of a Journey. The issue is that many are not considering the longer term strategy around SOA, and instead focusing on tactical activities with no common understanding of the desired end state. That's the issue I had with Dan's comment, and I stand by that. My point above is that you also may need to prove value of any long term strategies with many small wins to demonstrate value.

"While commenting more on Dave's flip-flopping would be rubbing salt in the wound, I think the advice I gave in the series of responses (1, 2, 3, 4) to Dave's original post are still appropriate as we enter the upcoming recession."

I don't think there will be a recession, by the way. You can quote me on that. :-)

Posted by Dave Linthicum on January 24, 2008 04:31 AM

January 22, 2008 | Comments: (0)

Why Some Enterprise Architects are Failing SOA

Download file

Posted by Dave Linthicum on January 22, 2008 10:20 AM

January 22, 2008 | Comments: (0)

Some Thoughts on Service Descriptions and SOA

With the advent of Web services, most enterprises that I deal with now have thousands sometimes tens of thousands of services under management. To make matters even more complex, we also have to consider services that are out of our direct control, those found on the open Internet (public services). Clearly, you can count on the number of these services increasing over time, perhaps very quickly over the next few years.

While we do have some interface information about these services, as defined by standards such as WSDL and UDDI, we really need a more complete set of info surrounding the services in order to create a proper SOA. This information should include things such as; the purpose, interfaces, parameters, rules, logic, owner, semantics, included services, and other important data. Let's call this what it is, a service descriptions.

I believe that before understanding the need for service descriptions, we need to first better understand what's information is already available within existing standards such as WSDL and UDDI.

However, there are a few more dimensions we need to address including: semantics, purpose, authentication, dependencies, and service levels. These by the way, are only basic suggestions, other dimensions and even sub-dimensions are all allowable.

Semantics, is a no brainer and it's been known for awhile that semantics are a weak point of Web services. Today we are attempting to solve this problem with new standards such as The Semantic Web, or more often through proprietary mechanisms, so I really don't need to sell this dimension. This is a pain point for most service-oriented integration architects.

Purpose means that we have a common notion of the purpose of the service, such as a service that's written to update cash in an accounting system, or a service that controls a large inventory system. Here we should document the uses of the service, examples, and any calling information needed.

Authentication would provide the security element to a service, including who's authorized to use it, identity management issues, and any special security issues such as the use of encryption.

Dependencies would define any other services encapsulated inside of a service where the calling service is dependent upon. For instance, an inventory control service may leverage a public service to determine the date and time, that needs to be documented as a dependency for obvious reasons (e.g., that service dies so does your service).

Finally, we need to define service levels. In other words, the service levels you can expect from a particular service including standard outages and accessibility issues, such as limited bandwidth. This will allow those creating a composite application around a group of services to determine the service levels of the composite application, which is only as good as the services that make up the composite application.

Clearly we need to go a few more levels of detail down to better define the notion of service description as well as the properties we need to track within each service. Perhaps we can meld this into an existing standard, much in the same way metadata is moving towards a standard (finally). However, I suspect it will still be the Wild West out there for awhile as SOA and service-oriented integration moves out of the playground and into business critical production systems. When that occurs we better have some sense of how to define, share, and leverage service description or it will be a very confusing world.

Posted by Dave Linthicum on January 22, 2008 06:36 AM

January 18, 2008 | Comments: (0)

More on Defending SOA

Just when I thought this topic was dead, I ran into this article by Rich Seeley that does a great job in highlighting the issues, and the defense of SOA as some budgets become tight.

"SearchSOA.com did its own survey of thought leaders who follow service-oriented architecture to see how they thought an economic downturn would impact SOA planning and implementation. Specifically, we asked this question: What will SOA need to achieve in an economic downturn to prove it deserves its agile-business, cost-savings hype?"

Neil Ward-Dutton, research director, Macehiter Ward-Dutton, provides the best advice. Naming 3 key things that companies can do to defend SOA.

"First: transform your approach to software delivery incrementally, focusing initially on one or two areas where you know that change is going to happen and keep happening. Use SOA to minimize the future cost of change in one or two high-profile areas like this and you'll demonstrate how IT can minimize costs and still support ongoing innovation.

Second: set up a small "center of excellence" to lead these projects and develop skills and helping educate everyone else.

Third: get your center of excellence to really collaborate with the business – to learn about the most suitable problems to tackle; to help measure the impact of the shift to SOA and to turn them into champions for further transformation."

And, some advice from myself.

"SOA always needs to prove its value and during times of economic uncertainly, where capital budgets are contracting, the best approach is to focus on short term objectives that are directly related to the generation or revenue. This does not replace a long term SOA strategy, which is very important, it's just a way to provide leadership with proof points to justify the continued investment. Perhaps the service enablement of the existing legacy systems to provide better interfaces for trading partners or the ability to abstract processes/services into configurable domains, thus allowing processes to change without a great deal of latency and cost.

The number and types of high-value projects should be obvious. In essence, prove that the investment in SOA should increase during a downturn, considering that the ROI is very high."

Okay, things are getting tight, and SOA is going to need some defending. Hopefully I've armed you with some key issues to consider.

Posted by Dave Linthicum on January 18, 2008 05:00 AM

January 16, 2008 | Comments: (0)

Notes from OMG’s Maximizing BPM Investments with SOA Workshop Presentation…With Audio

I did my presentation at OMG's Maximizing BPM Investments with SOA Workshop held in Orlando FL this morning. It was very nice of OMG to invite me, and very good questions from those attending. Here is the complete recording of my presentation. If you're looking for the slides, drop me an e-mail here.

Overall I'm not sure why we are still linking SOA with BPM, the links to me a clear and already established. Indeed SOA is about abstraction of services into a layer that supports configuration, more so than programming. More often than not that's going to be a process, workflow, or SOBA layer. The ability to place volatility into a single domain provides the agility aspect of SOA, and thus process is a very important concept within SOA.

I think those who heard my talk this morning already got that, but do the rest of you?

Enjoy the presentation. Let me know what you think.

Posted by Dave Linthicum on January 16, 2008 01:21 PM

January 15, 2008 | Comments: (0)

SOA and Budget Cuts

Download file

Posted by Dave Linthicum on January 15, 2008 08:32 AM

January 14, 2008 | Comments: (0)

SOA is Vertical? When Was It Not Vertical?

I got a kick out of this article announcing a new "vertical SOA offering" from IBM.

"With the launch of something it calls the Retail Integration Framework (RIF), IBM this week gave prospective customers and its competitors a preview of what it has in store for SOA-enablement (define) in the coming year.

RIF isn't a product but rather an enterprise software architecture, or framework, designed to help fill in the gaps between packaged software applications and legacy systems to help speed the implementation of new customer-focused strategies and technology initiatives in an SOA environment."

Somebody is not getting SOA. Indeed, SOA is not predefined services and processes that adhere to some type of business pattern…it's an architecture that's able to support any type of business pattern. This is something that vendors pull often, the vertical-ization of technology to provide a differentiator. To be fair, I did this when I was the CTO of Mercator, in essence creating specific application integration solutions for healthcare, manufacturing, retail, and finance to sell integration. It worked. But, that was integration not SOA.

SOA, however, is a bit of a different animal. It's really about creating something that changeable and agile, and the vertical component parts are really instances of solutions. In other words, SOA is the ability to configure the parts, and not necessary the parts itself. Or, it's always a vertical solution since you can easily configure it into solutions, including verticals. Get it?

This is one of those things that I knew would come from the vendors eventually, but actually demonstrates a lack of understanding of the concept of SOA. However, I understand why they are doing it, and I'm sure a few of you will find it of value. This goes to the fact that I've stated many times: Architecture is difficult to understand and sell, thus many attempt to revert to gimmicks. Gimmicks don't provide the value of architecture, unfortunately.

Posted by Dave Linthicum on January 14, 2008 05:21 AM

January 11, 2008 | Comments: (0)

Is SOA a “Special Project?”

I had some interesting responses to my post yesterday relating to SOA projects, and cutting the budget.

From Joe McKendrick's blog:

"As I observed in a post just a couple of days ago, Brenda Michelson spoke to various SOA Consortium members, and the consensus was that SOA efforts would press on through a rocky economy, and even help to better streamline operations.

Are SOA projects typically viewed as overhead, or are they seen as an effective mechanism to help organizations better manage costs? How would your company view SOA if it had to trim its IT budget?"

Joe even put up a poll around this topic…check it out.

Another more business-oriented post came from Alastair Bathgate. I thought his insights where most helpful.

"My personal view is that budget holders will give much more support to business case and $ ROI arguments than any other justifications. However, the current climate is very short term. Most enterprises are focused on short term cash and short term profit. Directors are targeted on short term measures. They are also ever less likely to hold their role for more than 2 years.

So when you try to justify your project, bear this in mind. There is no point in demonstrating that your $25M investment will pay back handsomely over 10 years. You must find ways of proving that your project will deliver incremental short term benefits so the longer term project funds itself and delivers ongoing business value as well."

I can't argue with that, and even during good times demonstrating short term tactical ROI, along with longer term strategic ROI, is just a good idea to keep the SOA momentum moving along.

What's frustrating about all this is that SOA is really about a systemic change in the way we do IT, and not really a "special project." Within most enterprises SOA, like data warehousing, EAI, B2B, etc., are all considered to be "newer technologies," and/or approaches, and thus should be considered an "experiment" in the minds of those writing the budgets. SOA is not about technology, it's about architecture. The sooner everyone gets that the sooner it won't be on the list of "special projects."

Posted by Dave Linthicum on January 11, 2008 04:59 AM

January 10, 2008 | Comments: (0)

Budget Cuts and SOA

There seem to a few companies that are cutting their SOA efforts due to the softening of the economy. No matter if you think its oil prices, the mortgage crisis, or other factors, in many organizations capital budgets, including IT, are being reduced.

Thus, what gets cut first? Any special projects, such as SOA. However, that could be a critical mistake.

Indeed, much of the money that's leaking out of an enterprise is not in the form of "special projects" but the cost of leveraging a less than optimal architecture and technology. The metrics are clear, bad architectures cost millions a year in lost time and productivity, not allowing for the enterprise to be as agile as it needs to be. However, management typically fails to understand this, until it becomes a critical issue that could bring down the company.

So, is your SOA project getting cut? Here are a few things you need to consider:

First, make sure everyone understands the lost ROI and impact on the enterprise, and do this in dollar figures. You'll be surprise how much money is being saved, and made, well inline with the investment. You need to make sure you do the analysis. If you can't defend it, than perhaps the project should be cancelled. Keep that in mind.

Second, attempt to shift resources from existing projects to the SOA project. Chances are, you have a few of those around. While it's a huge political football, once you do the analysis you could find that SOA is much better use for the money.

Finally, if the cuts can't be stopped, plan for the downtime. Make sure that the resources are maintained until you need them again, else the restart will cost much more than it should.

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert