Real World SOA | David Linthicum | July 2007

MORE ENTRIES

July 2007

July 31, 2007 | Comments: (0)

About the Keynote at Open Group

Download file

Posted by Dave Linthicum on July 31, 2007 05:54 AM

July 30, 2007 | Comments: (0)

Looking for Candidate Services

Those of you using my SOA methodology already know that one of the things I ask for is that you look for candidate services. Candidate services, simple put, are services that have the potential to become core services, but that requires a bit more analysis before they do.

The fact is most services employed within SOAs exist already. Thus, part of the process of building a successful SOA is figuring out what should be a service, and what should not. A common amateur mistake is to service enable everything. That typically proves unproductive, and could be a "SOA killer" at the end of the day.

While there are no hard and fast guidelines on what makes up a well-defined and developed service, I do know a few things:

Services are not complete applications or systems. They are small parts of an application, and should be tested as such. Services are not subsystems; they are small parts of subsystems as well. Indeed, services are more analogous to traditional application functions in terms of design, and how they are leveraged to form solutions, fine or course grained. Knowing that, we have a better basis of understanding when approaching the service testing problem.
Each service has a specific purpose, and they are not complex or naturally dependent upon other services. Thus, they are easily abstracted into composite applications, in essence, leveraging these services as if they are functions local to the composite.
Services should exist with a high degree of autonomy. They should execute without dependencies, if at all possible. This allows you to leverage the service by itself, and design the service with this in mind, no matter how course or fine grained the service is.

Posted by Dave Linthicum on July 30, 2007 05:25 AM

July 27, 2007 | Comments: (0)

More on the SOA/EA Thing

Not that I wanted to make this SOA vs. EA week, but it has been an interesting angle to each topic, and the bloggers continue to pick up on it. Typically, they are referring to the comments I made during Monday's keynote at the Open Group Conference in Austin.

I think I've said all that I can say on the topic, so it's interesting to hear others talk about it. A few to point out:

In Loraine Lawson's blog, she points out:

"It seems obvious that SOA would help with EA, but since SOA is still in the early stages of adoption, everyone's still trying to figure out how SOA will fit in with EA.

The answer, according to a recent white paper from The Open Group, David Linthicum and various others, is simply that SOA is an architecture that supports services and, therefore, one way to do EA. Eventually, SOA will become a core EA discipline. That makes sense."

And from Eric Roch's blog post:

"SOA should be a part of Enterprise Architecture (EA) from a top-down perspective, but there is also a lot of tactical work to be done with SOA that is more aligned with what many companies call solution or application architects. The bottom-up plumbing of SOA still has to be done and that is project based."

Finally, Tony Baer's article, Bridging the gulf between SOA and enterprise architecture, where he states:

"By and large, EAs as a group have only recently begun embracing SOA. For instance, many in this group still fear SOA as opening up the floodgates to enterprise IT assets in a manner that will be difficult to control. In effect, because SOA is supposed to make it easy, it would make it too easy to let software developers-turned-SOA project teams expose data and application functions in much the same way taking the familiar shortcuts to turning out quick results without concern for how their programs could be maintained in the long run."

I have to say I agree with all that's being said around SOA and EA working together, and I think now is the time to find the synergy between the two.

One of the dangers I see out there is the fact that the Enterprise Architects typically have more political juice within enterprises. Thus, if they view SOA as a threat, they could convince those in charge to ignore it. Or worse, say it has been assimilated into EA, when it has really just been ignored. I hope that won't happen, but if it does, I'll be there to point it out.

I'm cutting back on my public speaking to focus more on my clients. However, I would be happy to speak at the Open Group event again, they seem to be addressing the issues around SOA and EA, by framing the discussions. That's just healthy.

Posted by Dave Linthicum on July 27, 2007 06:18 AM

July 25, 2007 | Comments: (0)

Linthicum's Comments at the Open Group Conference Blows Up the SOA Blogosphere!

You never know what kind of impact a comment made at a speaking event will have. That is, unless you have 4 other SOA blogger in the audience at the time.

During my keynote address on Monday at the Open Group's conference held in Austin Texas I stated that:

"Five years from now, we won't be talking about SOA… It will all be folded into EA."

Meaning that SOA does not change, but it just meshes with other architectural concepts that are already existing and adding value. Indeed, in some instances SOA will become EA. In other instances, EA will learn to adopt and change around SOA. Thus, in 5 years we will just be talking about "architecture." That was core to my point.

Provocative? Not really. It was interesting to read the responses from the bloggers in the audience who posted my comments, and their thoughts, before I finished my talk. Indeed, one of my clients sent me a blog posting about my talk, via e-mail, before I got back to my seat. What a world we live in now, actually kind of neat.

Here are the 4 that I found.

Dana Gardner

"In effect, Linthicum said, SOA is just good EA. The goals for each are ultimately the same: To get better at building agile IT architectures and to make change the number one requirement for IT.

But that's not what you'll find on the street. In many cases those planning SOAs are not in synch with those that are keeping the trains running on time, so to speak, inside enterprise datacenters. Linthicum pointed out that there are currently "two worlds out there," enterprise architects and SOA architects, with one working up from the existing IT landscape and the other working down, respectively, from the larger concepts of agility, reuse and orchestration of service points."

I thought Dana did a good job in capturing what I was attempting to communicate. "SOA is good EA." Thus, in a few years we won't be talking about SOA as much as just architecture.

"So what are the next steps to make EA and SOA act in concert? How can the will of the organization at large be cultivated to support the $7 million to $10 million needed for even a medium-sized business to meaningfully implement SOA?

Linthicum recommends that IT leaders see beyond the SOA hype, to encourage enterprise architects to become advocates for positive change that embraces SOA principles and methods. He also says that SOA must play well with and embrace such mega trends such as SaaS, Web 2.0, application modernization, datacenter consolidation, and semantic data management."

Dana gets an A+ is coverage.

Todd Biske

"Right now, I'm sitting in David Linthicum's keynote, which is on EA & SOA. He had an interesting quote, which was:

'Five years from now, we won't be talking about SOA… It will all be folded back into EA.'

There's some truth to this, but there's also a lot of risk. One of the issues with EA (and many other efforts within IT), is that it can become disconnected from the project efforts that are going on. The term most frequently used with this is "ivory tower" where enterprise architects are simply viewed as paper pushers that know how to create a lot of PowerPoint slides. One of the side benefits of SOA is that it relates very well to the world of the development projects, with "service" being the point of common language. The enterprise architects may be modeling the enterprise in terms of the services that are needed, and projects can now utilize these models in their project architecture. This is easier said than done, however, as you need to ensure that the reference material containing these models (e.g. a reference architecture) is consumable at the project level. If the only group that can understand your models are fellow enterprise architects, that's a problem."

First of all, Todd got the quote right, and I agree with his assessment. My point is that SOA needs to work with existing enterprise architecture efforts out there. Right now, that's not happening. Indeed, SOA is an architectural pattern that adds value to EA. Thus, EA must change to leverage the notion of SOA, and SOA must learn how to work with existing EA.

More from Todd:

"So, will SOA be folded into EA as a whole? If EA can ensure that the artifacts it creates are consumable at the project level, then absolutely, SOA will be folded into EA. If EA is not creating artifacts that are consumable at the project level, then we have a problem. You'll likely still have tension between EA and SOA, and likely not being achieving the levels of success that organizations that have successfully bridged the world of EA and the project space. This doesn't apply solely to SOA. This applies equally to any architectural domain. You may have information architects working on canonical or enterprise data models, performing data quality analysis, etc., but if it doesn't find a way to become relevant to project efforts, it will exist on an island with continual struggles to achieve the objectives that were set out."

Tony Baer

"Keynoting the Open Group's Enterprise Architecture Practitioner's Conference this afternoon in Austin, colleague David Linthicum made a bold prediction: that in five years, SOA would get absorbed into the discipline of Enterprise Architecture within five years.

He characterized the current scenario in most organizations: that the EAs who tend to take the long view in planning what practices, platforms, and architectures should become enterprise standards, are largely speaking past the teams doing SOA projects who are concerned with meeting deadlines, delivering tactical results in manners that may at cross-purposes to what the EAs are talking."

And, went on to say:

"As you might guess, my colleagues (and fellow panelists later this afternoon) Todd Biske and Dana Gardner also had a few things to say about this. Both agree that ultimately this is the goal – you can't harness the benefits of SOA if you simply expose the same old silos with interfaces that are just a bit more modern."

And finally, from Beth Gold-Bernstein.

"David Linthicum delivered the keynote, and spoke of SOA as a subset of IT Enterprise Architecture. In fact, he stated that SOA is really just good architecture. Have to agree with him there – it's been a known best practice for decades. "

So far, so good.

"Then he said that in 5 years there will be no such thing as SOA – it will just be architecture."

Nope, never said that exactly. Actually, Todd got the quote right (see above). There will always be such thing as a SOA, it will just be talked about in context of architecture. The buzzword, and architectural design pattern, will be absorbed into existing and future architectural practices.

Normally Beth is spot on, but she missed the point on this one. I'm thinking my brut good looks must have distracted her. :-)

She goes on to say:

"My take is that while SOA definitely needs to be brought into the IT governance fold, it is not just an enterprise architecture issue. It fundamentally changes the way applications are developed. It's going to be a while to transition the developers skill sets. So as a term SOA will likely stay around for a while."

I don't think the value or the notion of SOA will go away, it will just be discussed in the context of architecture in general (Okay, I'm being redundant). So, just to be clear, I'm not announcing the death of SOA, but that it will have a core systemic value going forward….always, within architecture.

Interesting in the way the bloggers took the comments, and the audience as well I'm sure.

I'm glad I have a blog to respond.

Posted by Dave Linthicum on July 25, 2007 11:43 AM

July 25, 2007 | Comments: (0)

Can Enterprise Architecture and SOA Work Together?

Download file

Posted by Dave Linthicum on July 25, 2007 10:53 AM

July 23, 2007 | Comments: (0)

Speaking at the Open Group Conference Today

In Austin today speaking at the 15^th Enterprise Architecture Practitioners Conference run by The Open Group. I did the keynote this morning.

A few notes from the conference:

SOA is now an official EA concept, and they are thinking long and hard as to how SOA works with existing EA efforts. We covered a lot of that in the Webinar I did last week.
They presented the Open Group SOA Framework this morning, outlining the layers they are using to layer SOA into "traditional" EA. In essence how services, service components, business processes, and service consumers all work together.
SOA may be something that has a lifecycle unto itself, and at some point SOA may be assimilated into EA as a core discipline. I think this is true, but SOA is clearly going to have a life as a concept based on the amount of money being spent now.
SOA Governance is a mechanism to align business value with the SOA. In essence allowing the architect to quickly align the proper services with the business processes that needs them. The Open Group is doing more work on defining SOA Governance.
Service Lifecycle Management is something that the Open Group is addressing, in essence how you manage the lifecycle of a particular service. To me, this should be wrapped back up into SOA governance.
They view business process as core to SOA. I can't argue with that, indeed SOA is about abstraction of service invocation and data movement back into the process or orchestration layers.
Finally, semantic modeling is key to understanding SOA. Thus you need to create: Classification and Business Dictionary, Policies and Constraints, and Service Relationships. This goes to my methodology, but it's good to see validation.

All and all a good day in Austin.

Posted by Dave Linthicum on July 23, 2007 08:14 AM

July 20, 2007 | Comments: (0)

Can EA and SOA Get Along?

That was the question asked during this week's Webinar that I did with EA Directions and my firm. You can find the presentation and audio here.

So, what did we learn?

First, Enterprise Architecture (EA) is still a valid discipline within most of the enterprises today, and SOA needs to both add value and assimilate. While many think replacement, that's typically not realistic. Indeed, enterprise architecture brings its own set of disciplines not inclusive to SOA. I agree with this.

Second, EA provides a management framework that SOA can leverage. That's true, indeed the "city planning" aspect of SOA needs to lean heavily on the existing EA efforts, tools, and methods.

Finally, one of the steps to a good healthy SOA, is attempting to figure out the synergy with existing EA approaches within the enterprise. Learn to leverage what's work, and don't try to solve problems that have already been solved.

Hope you enjoy the Webinar.

Posted by Dave Linthicum on July 20, 2007 09:32 AM

July 17, 2007 | Comments: (0)

Am I Done with My SOA?

For those building SOAs in their organization…how do they know when to stop, or slow down? I mean, you can service enable and orchestrate the entire enterprise, perhaps your supply chains as well, but I doubt the cost of doing that is going to justify the benefits on most cases. However, clearly you can do to little, and thus not get the benefits you need. You need to find a balance.

So, we are assuming that there comes a time in the implementation of a SOA when the effort has a diminishing return or the point when the amount of effort won't produce enough value to justify continued work at the same level of effort. So, how do you figure that out?

So, consider the amount of effort over time as EOT, and the value of agility as VA and the value of reuse as VR. We're assuming that VA and VR change as EOT changes, over time, the trick is to determine the degree of change, or relative value, and how that relates to EOT over time.

Thus,

Relative Value = (EOT * (VA + VR)

As an example, let's say that EOT is a constant 25 percent of resources, typically as to how SOA projects work. Furthermore, we're assuming that VA diminishes by 10 percent yearly and VR diminishes by 5 percent yearly…again, back to my ROI article.

Thus,

Year EOT VA VR RV

1 0.25% 90 95 0.4625

2 0.25% 81 90.25 0.428125

3 0.25% 72.9 85.7375 0.39659375

4 0.25% 65.61 81.450625 0.367651563

5 0.25% 59.049 77.37809375 0.341067734

6 0.25% 53.1441 73.50918906 0.316633223

7 0.25% 47.82969 69.83372961 0.294158549

8 0.25% 43.046721 66.34204313 0.27347191

9 0.25% 38.7420489 63.02494097 0.254417475

10 0.25% 34.86784401 59.87369392 0.236853845

11 0.25% 31.38105961 56.88000923 0.220652672

12 0.25% 28.24295365 54.03600877 0.205697406

So, it looks like year 5 or 6 is the time when it makes sense to ramp down the efforts, else suffer diminishing return. Once again, just a set of data points to assist you in making a decision.

Posted by Dave Linthicum on July 17, 2007 02:32 PM

July 16, 2007 | Comments: (0)

Moving SOA to Verticals

Download file

Posted by Dave Linthicum on July 16, 2007 01:55 PM

July 14, 2007 | Comments: (0)

More on the Common Data Model Thing

Sometimes when I find other blogs referring to my blog it's just a matter of reflection…"here's a good idea" and all that. Sometimes, however, they add good ideas. Case in point is Jean-Jacques Dubray's post on InfoQ that addresses my post last week on the Common Data Model, and dealing with it within an SOA.

From the article:

"David's experience shows that relying on a common set of schemas may prove to be inflexible when designing service interfaces because 'it will prevent these services to evolve separately'.

SOA is about creating assets which can be reused in different contexts, often in context unknown at design time, and maximizing the benefits of SOA amounts to maximizing the reuse of your services by the largest set of consumers possible. However, it would be naïve to think that consumers will always be in the position to adopt the point of view of the provider or that both the provider and the consumer can always adopt the same point of view. Even if this were true today, overtime, the consumer and provider may not be in the position to evolve at the same time towards a newer version of the interface."

The point is that services are dynamic little creatures, and their need for data varies from service to service. Attempting to adapt to a common static structure is almost imposable…albeit it looks good on paper. The notion of conformity never works in the world of data, or the world of integration. The need to see information in the context of dynamics semantics is just too compelling and valuable.

Jean-Jacques goes on to discuss how to deal with semantic differences, or transformations.

"The first steps towards more manageable transformations, is to capture the semantics of the information contained in your messages and derive consumer and provider interfaces from these semantics. This is what Dave calls an 'abstraction layer' or others call a canonical data model or an ontology. In this abstraction layer, the structure is less important than the normalization of the semantics. This problem is not new, David Webber, way back in 1998 had introduced the concept of bizcodes, to normalize diverging names XML formats and deal elegantly with localization. "

Addressing the use of ontologies in context of this problem domain is a good idea as well, and I've certainly written enough about ontologies, including in my last book, so I won't dwell on it here. I consider ontologies a good approach when dealing with complex semantic domains, albeit I'm not sure too many people outside of Jean-Jacques, and a few others would agree with me. Indeed, we seem to all collectivity talk about how ontologies are a great idea, and nothing seems to come of it in terms of mass movements towards that approach. Perhaps the day of ontologies is coming; I'm clearing seeing an interest in using them within my practice, and I've made them part of my methodology.

"Semantics have to be managed precisely under strict governance processes and tested as Dave points out. Traceability to physical artifacts such as a service interface definition or a database schema are key to develop a successful ontology.

Here are some details about using an ontology in a Service Oriented Architecture:

a) Service interface need to be designed from the ontology (with their own structure, but utilizing the semantics of the ontology and only these ones)

b) For arbitrary consumers and providers, the design and implementation of transformations is greatly facilitated by the traceability established earlier between the ontology and service interfaces, and if they were designed from the same ontology, some of the transformation could be automated or directly inferred."

More good ideas.

Posted by Dave Linthicum on July 14, 2007 05:25 AM

July 12, 2007 | Comments: (0)

IBM Pushes Business not Technology...Okay

It had to happen, just when a space gets hot somebody had to state the obvious…"It's about the business." That's the case with IBM this week announcing eight industry-specific roadmaps for SOA. IBM also announced the results of a sponsored customer survey supporting their new strategy.

From this article in Network World.

"Rather than upcoming products from IBM, the eight roadmaps detail an implementation framework for six specific industries: one each for banking, insurance, retail and manufacturing, and two each for telecommunications and healthcare, which IBM says are its biggest customers. In most cases, the underlying mix of IBM application platform and SOA middleware products is not significantly different between the roadmaps, though IBM and some of its ISVs have developed industry-specific components that run on top of the platform."

"It's the vertical dummy," is what they are saying. Indeed, history is repeating itself here. After application integration got boring back in the EAI days, we moved into vertical specific solutions. At Mercator, for example, we made a nice business around HIPPA and the health care vertical, same thing with banking. IBM is attempting the same thing here by providing "industry-components." Not sure this is neither innovative nor new; it's really expected at this point.

"The theory is that because SOA is all about service re-use, different enterprises within a given industry will be able to reuse the same services, even if their underlying applications and business processes are not identical. This strategy should be more flexible than monolithic single-industry approaches and simpler than building everything from scratch. "

This has always been to core notion of SOA, the ability to mix and match services, vertical or not, to form solutions. I would, however, argue based on what I'm finding that SOA is all about agility, with reuse being a side benefit and required for agility. But, I won't make a big deal about that now.

The notion that SOA is all about business is correct, but I'm not sure there is anything new about that. However, it's the combination of business needs with the right best-of-breed technology that provides the maximum benefit. Moreover, considering services and processes that are specific to your business is just good architecture. I'm sure IBM knows that, as do we all.

Posted by Dave Linthicum on July 12, 2007 06:40 AM

July 11, 2007 | Comments: (0)

Common Data Model and SOA

Download file

Posted by Dave Linthicum on July 11, 2007 10:10 AM

July 10, 2007 | Comments: (0)

New "Greg the Architect."

Tibco has done a good job with this series, got to give them that. Here is the latest. Enjoy.

Posted by Dave Linthicum on July 10, 2007 06:00 AM

July 09, 2007 | Comments: (0)

Where have all the SOA Standards Gone?

When standards are created in the SOA space I mark the occasion by creating a Google Alert for that standard, and then sifting through the piles of links to get the real scope on the maturation of a particular SOA standard. To date, I'm tracking over 60 standards, starting way back when with SOAP, and prior to that XML (XML was well before Google was cool).

Lately I've been noticing a drop-off in the number of blogs, links, and articles that are talking about particular SOA standards. Where I received links that numbered in the dozens, per week, for some standards, I'm receiving 1 or 2, or no links these days.

At first I figured it was just cyclical thing, but I think it's a real trend. The press, bloggers, and even the SOA companies themselves are getting weary of the number of SOA standards out there competing for hearts and minds, and are just not paying as much attention to them these days.

Even at the 7 SOA and enterprise architecture conferences I spoke at earlier this year it was clear that interest in standards is not driving SOA, but the notions of architecture modernization and agility is really in the forefront these days. While I don't think anyone is not considering standards when implementing a SOA, the notion of standards just does not seem to be driving the decisions as it once did.

I think this is silent push back from the years where the creation of SOA standards was more about marketing then coming together on the implementation of technology. I think the end users have figured that out, and considering the sheer number of standards out there that the vendors are asking you to follow and support, many are just finding that world far too self serving and confusing. I'm not sure I can blame them.

Please don't get me wrong. Doing things in a standard way, using standards, is very important. Investment in standards could indeed lower some risks in the implementation and the maturation of an SOA. However, while rallying around a few key standards such is certainly important, no way can you figure out how 60 or more, some of which are competing, will fit into your SOA. Perhaps it was too much, too early, and too confusing.

Posted by Dave Linthicum on July 9, 2007 09:19 PM

July 03, 2007 | Comments: (0)

Using a Common Data Model with SOA

Lately I've been hearing a lot about common data models when it comes to SOA. As organizations attempt to figure out the data in the context of SOA they are driven many times to the notion of a common way to view data as a part of the architecture.

Case in point is this post from Kjell-Sverre Jerijærvi who points out the need and the notion of a common or Canonical "Data" Model.

"An important topic when designing service oriented systems is how to enable different services to share semantics to be able to be composed into working solutions."

While this is something I've been pushing for years, I'm now seeing some good thinking around this problem and some good technology behind it as well. The data is the single most important component of an SOA, and you need to think carefully about how the data is managed. Simply tightly coupling the data to the services won't serve the notion of agility, and you're really not solving your data problems.

"Making every service contract depend on the One True Schema will make it impossible for the services to evolve separately, they will no longer be autonomous."

Thus, the data is important, and you need to figure out management, aggregation, and abstraction approaches before you begin bolting on services. While many agree that starting with the data is a sound approach, the majority of SOA projects I see are starting with the services, and working back to the data. While that's not a horrible approach, you'll find that you'll be redesigning and redefining services after you figure out your data layer, and in many instances the services will have to change significantly.

Some key takeaways from all this:

You need to face the data first and define a common data or abstraction layer so that the services are not bound to a particular schema, but enjoy the use of the data nonetheless. I would not push a common schema as much as an abstraction layer.
The abstracted or common model should be tested like any other component.
Don't focus as much on force fitting a data model as agreement across the service domains, and leverage a schema mapping layer to provide choices in the future and agility down at the data layer.

Posted by Dave Linthicum on July 3, 2007 05:13 AM

July 03, 2007 | Comments: (0)

The Need to Focus on the A in SOA

Download file

Posted by Dave Linthicum on July 3, 2007 04:47 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •