Real World SOA | David Linthicum | August 2006

MORE ENTRIES

August 2006

August 30, 2006 | Comments: (0)

Kris Zywicki was nice enough to alert me to this article, "Analysts see Java EE dying in an SOA world." The article states:

"Java Platform, Enterprise Edition (Java EE) is not going to survive as a major standard programming model in the next five years, predicts Richard Monson-Haefel, senior analyst with the Burton Group, and SOA is part of the reason."

Richard points out the fact that the new requirements of SOA may not work and play well with the way most enterprises will create and implement a SOA. What's more Jason Bloomberg of ZapThink jumps up and down on J2EE at the same time.

"'Java EE's days have been numbered for a while now,' said Jason Bloomberg, senior analyst with ZapThink LLC, who also sees the main culprit being the increased complexity that comes with each new version."

What’s interesting here is the Java/J2EE has been getting a bad rap lately, specifically with the rise of the Web 2.0 and the popularity of new tools such as Ruby on Rails. Indeed, many Java developers have jumped ship to Ruby, and developers, once religious about Java are moving on.

What is more, SOA seems to have special needs, and many such as Jason are finding that J2EE is much too complex for many, and does not match up to the requirements of most SOAs out there.

"Finally, ZapThink's Bloomberg said the Enterprise JavaBeans/Servlet/Java Server Pages framework doesn't jibe with SOA." ... "However, if you were to set out to create an enterprise-class framework for SOA, you'd build something quite different. You'd build a framework centered on enabling and maintaining the services abstraction layer so critical to SOA. So, while Java EE is well-suited for running platform-dependent services, it is not built for SOA."

While I agree that J2EE has it's limitations in the context of SOA, I also understand that many enterprises have already invested a lot in J2EE, and with press like this, are wondering about the future of that investment. The fact of the matter is that J2EE-based systems will work fine within most SOAs, if designed and implemented properly, so maintaining your original investment should not be an issue.

The larger question is: Does J2EE have a future in the world of SOA? With new development, I don’t think J2EE is the right technology in many circumstances for the reasons Jason states above. However, you need to figure that out for yourself, including current skill sets, existing technology, and technical and business requirements of your SOA.

It will be interesting to see how BEA and IBM react to this recent news. Can you say multiple white papers?

Posted by Dave Linthicum on August 30, 2006 05:56 AM

August 28, 2006 | Comments: (0)

Is There Still A in SOA? and Step 6 of my 12 Steps to SOA

Is Still There A in SOA? and Step 6 of my 12 Steps to SOA

Download file

Posted by Dave Linthicum on August 28, 2006 07:56 PM

August 28, 2006 | Comments: (0)

Some Random SOA Thoughts over the Weekend

First, most SOA architects (or should I say SOAAs [Okay, I won't]), are doing a poor job in convincing the powers that be that be that SOA is a good idea. I'm hearing this a lot, and considering the investment this is going to be a major issue in moving existing "crappy architectures" to SOA. However, you have to consider that many asking for SOA money are those that built to "crappy architectures" in the first place; I guess I can see the point of management in some cases.

So, what do you do? Basics kids. Define the value as a business case. That means we’re not doing SOA because it's cool, but because it makes a better business. Focus on that. It's not a fix, it's moving to improve. It's not a project, it's a journey.

Second, performance and security are systemic, thus must be considered throughout the architecture. Many are only considering those notions as a part of the process. That's a mistake, and will force you to change out technology later, and will cost valuable time and money.

Finally, focus on small successes at this point. As you saw in the Oracle case studies I blogged about last week, the first instances of SOA are much more simplistic. That's good; you build from the ground up and do so in baby steps.

Posted by Dave Linthicum on August 28, 2006 06:25 AM

August 26, 2006 | Comments: (0)

SOA Speaking Season is Here

It's almost September, and what does that mean? The start of speaking season of course. This Fall SOA conferences are plentiful, and I'll be speaking at most of them. Moreover, at a few other "SOA linked" conference as well.

Here's my schedule, please feel free to stop in and heckle me...I like animal noises the best.

September 12th, The eGov Institute 6th Enterprise Architecture Conference. Washington DC.

September 19th, Strategies for Developing, Managing and Governing
Service-Oriented Architectures, Washington DC.

September 25th, SaaS Con. I'm not speaking there, just hanging out with a press pass. San Francisco.

October 11th and 12th, 12 Steps to SOA Seminar. Paris. No, I do not speak French.

October 24th - 26th, Enterprise Architecture Conference. San Diego.

October 31, 2nd Service-Oriented Architectures for E-Government Conference. McLean Virginia.

November 7th and 8th. InfoWorld SOA Executive Forum. New York.

November 21st and 22nd. SOA Congress. Frankfort.

Busy season.

Posted by Dave Linthicum on August 26, 2006 08:15 AM

August 25, 2006 | Comments: (0)

Is Architecture out of Service Oriented Architecture?

In looking the latest stories and articles about SOA, it seems to me that many are no longer thinking about the A...architecture.

Why do I think this? Just look at the press, the focus is on the technology instances, and not the overall architectural challenges. Thus, SOA is an ESB, SOA is governance, SOA is programming, but SOA is almost never an architecture. This is a bad trend if you ask me.

Pushing this product-oriented agenda are the marketing departments at the various vendors. They don't know how to promote a notion, such as architecture, but do know how to promote a product. "SOA," the term is hot, thus they sell SOA, which to them is their product.

Therefore, there is much confusion with the end users; indeed many don't understand what SOA really is, and how to make it work. Moreover, they have simplified the concept so much that it won't do them much good and many are dragging in products looking for a quick fix that just won't happen. Remember: Think, analyze, understand, test, and then purchase the technology.

Repeat after me:

SOA is architecture, not a product.

The value of SOA is in the ability to create an agile and functional architecture which aligns with the business.

SOA requires a lot of upfront work before you select the proper technology set.

SOA is almost never a quick fix.

Sorry to stop the party, but somebody needs to say something. Focus on the A of SOA, and you'll be fine.

Posted by Dave Linthicum on August 25, 2006 06:07 AM

August 24, 2006 | Comments: (0)

Designing for Performance, Monitoring, and Optimizing

So, now that we know how to diagnose the performance of an SOA, as well as model for it to determine how it will behave in a changing environment, how do we design a service and SOA with optimized performance? Here are a few tips.

The more processing you can place at the origin of the service, the better your SOA will perform. In many SOAs, the architects abstract the services to a single server, and performance can be somewhat problematic in larger implementations.

Many services are built on top of more traditional legacy APIs, and as such the translations between legacy APIs to expose them as services may cause performance problems. The ability to leverage existing legacy systems as services is a powerful notion. However, you must be careful in selecting the proper enabling technology to do this. Service invocations that take a second or more to produce behavior, or information bound to behavior, will cause big problems when you align them with hundreds of other services that are doing the same thing.

The use of too many fine-grained services may cause performance problems. Indeed, you should not be afraid to leverage fine-grained services within your SOA. However, you need to understand the performance issues associated with doing so, and take the network bandwidth and how other applications leverage the services into careful consideration.

Make sure to consider performance when selecting your orchestration layer. Many BPEL engines are notoriously poor performers, and can become the bottleneck for the SOA.

Understand the basic rule that, while the value of an SOA is the ability to leverage many remote services, the more services you leverage, the more problematic your SOA will become.

Posted by Dave Linthicum on August 24, 2006 02:11 PM

August 22, 2006 | Comments: (0)

Getting Down to SOA Performance

As I've blogged about before, SOAs are not unlike any other distributed computing systems, and thus designing a performance model should be nothing too new. At this point we understand exactly how each service behaves under an increasing load, and we have enough data to plug into a model. Now, it's just a matter of building a model.

There are very expensive performance monitoring and simulation tools that are for sale in the market, but sometimes the least expensive and most simple tools work best...in many cases, just a spreadsheet will do. For our purposes, we need to consider both information and behavior in the context of performance, as well as core features of an SOA.

Information Movement Modeling, typically asynchronous in nature, means we're attempting to simulate how information moves from point to point, point to many points, or many points to many points. Based on the information we accumulated we know the:

Information production rate from a service
Information consumption rate from a service

For example, an instance of a service is able to produce 52 messages (or similar groupings of information) per second...the source service. An instance of a service is able to consume 34 messages per second...the target service. This is a simple point-to-point relationship, but keep in mind that multi-points to multi-points are always possible, and those are a bit more complex to model since you have to determine patterns of movement between multiple points vs. all messages produced by a single service that are consumed by another.

Moreover, keep in mind transformation and routing latency is typically an issue here as well, and needs to be modeled along with consumption and production. You should have test data from these services, but the performance of transformation and routing services will be largely dependent upon the complexities of the transformations and logic associated with the routing. What many do when creating performance models is to model very complex, complex, and simple transformation scenarios, and the percentages of each.

Service Invocation Modeling, typically more synchronous in nature, means we're attempting to determine the number of times a service is able to provide a behavior (application function) in an instance of time, typically a second.

For instance, you may have a service that provides a risk calculation for the insurance business, and is perhaps abstracted into several different applications (composites). We know through testing that each composite can invoke the service up to 100 times a second before it hits a saturation point, meaning the performance of the service quickly diminishes as additional load is placed upon it. This saturation number plugs into the model, as well as the number of applications that are abstracting this service. You have to model all of these services in the same way.

Models are important because they allow you to predict performance under changing needs without having to actually build and test the system. Models, of course, are not perfect, and you must constantly adjust assumptions and modeling information as you learn more about the behavior of the architecture.

Posted by Dave Linthicum on August 22, 2006 02:07 PM

August 22, 2006 | Comments: (0)

More on SOA and BPM and Step 5 of my 12 Steps to SOA

Download file

Posted by Dave Linthicum on August 22, 2006 10:59 AM

August 18, 2006 | Comments: (0)

SOA Case Studies Beginning to Emerge at Oracle

I get calls and e-mails from a lot of SOA vendors asking me to blog or write about their product...and fill up my inbox with megabytes of white papers and data sheets. I always ask for case studies, which is where the rubber meets the road, but I never hear from most them again. In short, vendor/SOA case studies are hard to come by.

However, I did have a couple of guys from Oracle grab me after my ROI talk at the last InfoWorld SOA Executive Summit. They were working on some research around ROI and case studies and wanted some input, which I gave them. The end result was this paper: Bringing SOA Value Patterns to Life.

If you can get beyond the marketing message (they are Oracle, after all) to the case studies towards the back, there are some good examples of early implementations of SOA, including a college that created a "SOA by accident." I love that one. Moreover, the more practical mainframe modernization SOA project case study...or putting SOA lipstick on your mainframe pig.

What I like about this kind of research is that they are studying the patterns of use, and thus will have a better understanding about the functionality of their products, or better yet, required future functionality of their products. Also, not only looking at how the technology solves technical problems, but the value that it brings to the bottom line of the business...that is most important.

Posted by Dave Linthicum on August 18, 2006 06:24 AM

August 17, 2006 | Comments: (0)

SOA Could be a Cuddly Fuzzy Bunny

Joe McKendrick had some good comments on my blog about "Fear of SOA," and made some good additional points:

"Let me add to Dave's thoughts that fear of SOA may also come from a healthy skepticism of vendors' overselling of SOA as a fix-all for tough integration problems or overblown IT budgets."

Yep. Can't argue with that.

So, what do we do? The vendors need to calm down a bit around the hype that's in this emerging space, and understand the value in context of the business problem. No magic bullets, and it's going to take some time to fix any integration problems, SOA or no SOA. That's just reality.

Perhaps the vendors should create a mascot. I'm thinking "SOA Sam"...a fuzzy bunny that you can put on your desk and hug whenever SOA begins to scare you.

Thus, we can consider SOA a cuddly fuzzy bunny that is just adorable. You can't be afraid of that, can you? As long as there is no SOA Sam 2.0, I'm okay with it.

Posted by Dave Linthicum on August 17, 2006 06:51 PM

August 16, 2006 | Comments: (0)

Fear of SOA and Step 4 of my 12 Steps to SOA

Download file

Posted by Dave Linthicum on August 16, 2006 06:49 AM

August 14, 2006 | Comments: (0)

Is SOA Boring?

Funny question to be asking when I'm posting to a SOA blog. However, I was thinking this weekend that indeed, if SOA is done right, and the right processes are in place, it's downright boring.

Case in point, the new notion that the SOA bloggers are diving at is ITIL, or IT Infrastructure Library. There is a good description of ITIL, and its relationship to SOA here. Albeit it's from IBM, so the end result is always an ESB. Not sure I agree with that. The requirements lead to the technology, and an ESB is only applicable in some cases, not all cases.

"ITIL is currently the most widely-adopted approach to IT service management available and provides a set of best-practice guidelines for IT service management developed by the British office of Government Commerce. The ITIL guide breaks down the key principles of the IT service management discipline into the following sub-categories, which are collectively known as the ITIL framework."

So, how does it relate to SOA? Well, once you get beyond the vendor stuff, it basically allows you to understand your domain, at the process, service, and semantic levels, and then apply SOA principals to that understanding, and manage the services going forward. Very much like my 12 steps to SOA, or other SOA methods for that matter, with a focus on management, and extending outside of SOA as well. It's the flavor of the month.

I came to a few conclusions this weekend.

First, truth-be-told it really does not matter what process or method you leverage to understand your enterprise problem domain best...ITIL, 12 steps, or your own approach, who cares? As long as you have a basic understanding of semantics, services, and processes so you can select the right solution.

Second, all of this process and mythology stuff we're bringing to SOA is kind of boring. I mean you're not playing with technology...instead service directories, process diagrams, and data dictionaries. What fun is that?

The reality is the core of architecture is not sexy. There is a lot of grunt work that has to occur before you get architecture right. Those who charge at this problem shouting: ESB! Governance! Data Integration! Or, whatever hype-driven buzzword is currently being tossed around, are more than likely to fail. So it's boring...but boring is good in this case.

If you want excitement, do some base jumping, extreme skiing, or shark wrestling...leave your enterprise alone.

Posted by Dave Linthicum on August 14, 2006 06:14 PM

August 11, 2006 | Comments: (0)

Is IT Scared of SOA?

Phil Wainewright did a good job in his blog making the case that many IT shops are afraid of SaaS.

"Two thirds of companies are missing out on the potential advantages of a SaaS solution simply because the IT department(s) are scared of trying SaaS,"

Phil confirmed what I've been blogging about for over a year now...the key challenge with the adoption of new and systemic technology is to get beyond the fear and control issues, of the existing IT staff. What's more, this is a SOA as well as a SaaS issue.

"deals are still lost because IT organizations start coming up with objections on the grounds of security, platform, control or some other alleged shortcoming. 'Whatever these objections are, they're really mythical objections. But the fears are real,'"

The problem with both SaaS and SOA (which I think are intermixed at a few levels), is that both technologies are so different from the current IT practices, and will change the fundamental way that IT works. Many in IT found those changes threatening to the way they operate today. The new approaches are scary for some reasons that are typically not real, but seem very real to them. Moreover, they have to give up some control to make the new approach valuable. That’s not something people like to do, generally.

I view the control issue as the underlying problem, and the largest barrier to implementing a SOA. You just can't get "traditional IT" guys to buy into the fact that their systems are going to both expose services, which is tough enough to deal with, but consume them as well? You then hear words of objection (or FUD) such as "security," "control," and "performance," just to name a few.

So, how do you get around these objections? There are a few simple steps:

Make sure that you define the value correctly. Many of those selling SOA, and I'm talking vendors and advocates within the company, make their pitches just assuming that they know "SOA is hip." However, you should assume that they don’t understand the value, and work the business case angle first, than their requirements, and only then the technology approach. They are correct in being weary of "magic bullets."

Anticipate the objections, and understand their validity. While you may see the objections as silly, they are indeed good points to bring up, and you must have good answers for each issue. How are you going to secure this new architecture? How well with it perform? How will they control it?

Not sure we'll ever be able to take the fear out of SOA in the short term. Only execution and success stories will raise the cloud of suspicion. Those are beginning to trickle in, fortunately.

Posted by Dave Linthicum on August 11, 2006 07:10 AM

August 09, 2006 | Comments: (0)

Open SOA Collaboration and Step 3 of my 12 Steps to SOA

Download file

Posted by Dave Linthicum on August 9, 2006 06:50 AM

August 09, 2006 | Comments: (0)

Can your Enterprise See the Emerging Web?

Web 2.0 is one of those marketing words I don't like to use that often, but unlike SOA 2.0, the Web 2.0 is a reality. It's really a change in platform at its essence, but there are also many social issues there as well...information sharing, collaboration, and social networking to name a few. I always enjoy reading Dion's stuff, he's Mr. Web 2.0 as it seems, but also focuses on making the Web work and play well with existing and emerging enterprises, that's key. But can your enterprise see the emerging Web?

What's important to remember is that there is a huge resource that is being created on the Web these days. This includes access to SaaS applications, such as Salesforce.com, that are better than their enterprise bound counterparts, service marketplaces, such as StrikeIron, and even mash-able applications that you can mix and match with other Web 2.0 applications or enterprise applications to solve business problem quickly.

However, having such a resource available for the price of a broad-band connection does not mean you'll be able to leverage it properly. Indeed, it's going to take some time before your enterprise is prepared to leverage the emerging Web beyond the browser. The best way is to design and deploy the first generation SOA with the Web 2.0 in mind, or in other words making your enterprises systems "exposable" to services or applications outside of your firewall, or "able to consume" the same services or applications. This is harder than it sounds, and chances are your current systems can’t see outside of their own operating systems.

Truth-be-told most SOAs will have the side benefit of being able to leverage the Web 2.0 stuff as a resource, services for example, but I assert that you need to design for that in order to make your infrastructure most effective. This means cataloging and testing services you don't own, attempting to mashup systems inside and outside of your firewalls, and making sure your security planning considers this notion as well. Many who don't plan for this will be stuck with an enterprise that can't see the new Web, and I think those enterprises will have a huge strategic disadvantage in the years to come.

Posted by Dave Linthicum on August 9, 2006 06:02 AM

August 07, 2006 | Comments: (0)

More Synergy between Mashups and SOA

I've been spending my weekends cruising around looking for examples of mashups, which are now hot, but I'm pretty sure few enterprise architects understand them. A few blogs ago I covered the differences between non-visual and visual mashups, and perhaps now it's time to look for examples.

You may want to check out DataMashups.com, which not only provides a tool to create mashups but a few sample mashups as well, that exhibit elements of both types. What's unique about these samples is that a few are moving away from the typically "addresses with Google Maps" samples that are all over the place these days, to things that are a bit more complex and useful. For instance, using the REST API out of Amazon to locate books, and perhaps mash that up with your own inventory, or whatever application you can think of.

Although these are very primitive when you consider the complexities of enterprise applications, the real value here is understanding the potential applications of this notion, including what I see as the real key values:

Agility. Of course. Creating applications and re-creating applications to drive enterprise information requirements. Moreover, leveraging many SaaS delivered applications in this mix as well.

Cost. It's much cheaper to leverage applications and services that are pre-built, and many that are offered at little or no cost. Also, you'll need much less local infrastructure.

Coolness. This is really the destination for SOA, Web 2.0, application development, and information usage. Thus, you might as well get on board now...and you have to admit it's very cool.

Posted by Dave Linthicum on August 7, 2006 11:20 AM

August 06, 2006 | Comments: (0)

Podcast Voice Mail Line Working Again

Sorry. I know a few of you had left message on my voice mail line, and never got a response. The line was not working, or at least I was not getting the messages. Anyway, please try again.

I'll use them on the Podcast if the question is good. Be the envy of all of your SOA friends. :-)

The line is: 206-202-3413

Posted by Dave Linthicum on August 6, 2006 06:30 AM

August 04, 2006 | Comments: (0)

Small SOA Companies Continue to Disappear

More SOA buyouts to talk about. The latest is IBMs bid to acquire MRO "driven by SOA desire."

"A day after making its third SOA (service-oriented architecture) acquisition, IBM was at it again Thursday. IBM announced plans to buy industrial asset management software vendor MRO Software for about $740 million in large part to help it develop repeatable services based on SOAs."

Moreover, IBM confirmed Wednesday that it had bought Webify Solutions, a small privately held provider of SOA development and deployment software and services specifically targeting the health-care and insurance industries.

Here we go again...and again...and again. As I pointed out in this past blog, the small SOA technology companies (< 1000 employees) are purchased faster than 2 dollar gasoline these days, and this trend does not seem to be letting up.

I'm not sure if I'm disturbed, or exciting about this. I do think most of the innovation out there is occurring in the small venture-backed companies, and while guys like IBM will always be a powerhouse with SOA, it just seems unnatural to me that so many SOA companies, before SOA is pervasive, are becoming parts of larger behemoths.

However, this does mean that the VC out there will be liking this space more, and thus provide more investment. This means more SOA startups, perhaps too many for the larger guys to eat.

Posted by Dave Linthicum on August 4, 2006 06:16 AM

August 02, 2006 | Comments: (0)

Observation: You Can't do SOA by Committee

Just got a friendly e-mail asking me to dial into a conference call at a large Global 2000 company, and speak to a group of people about SOA. However, this was not just a group of people interested in learning about SOA, but the "SOA Committee," a group made up of all IT leaders at this huge behemoth. I really have to ask more questions before accepting these meetings.

Quickly into the call I figured out that this was 5 people, all mini-CIOs at this corporation, and formed a committee to bring SOA to their company. However, I also quickly figured out that this committee was going nowhere fast.

Indeed, it became apparent that I was not there to inform, but there to become the mediator within this little war that had broken out between the committee members, as to the "right technology" to employ. What else? I did the best I could to assist them, but the final answer was to ask them to go back and understand their own requirements...they had no semantic or service level understanding of their domains. Nobody seems to like that answer, by the way, it's kind of like "do your home work" to a 9-year-old.

Just few lessons you can learn by the mistakes of this committee:

First, don't form a committee! You need a single person, the architect, to make the tough calls around requirements gathering, standards to leverage, agents of change, and finally the enabling technology. That person needs complete authority, and attaching him or her to a committee will just slow things down and ultimately put the SOA implementations at high risk, high cost, or both. They can work with many IT leaders in the organization, but this can't be a matter of the influence, but true authority. Most large organizations which are highly political, don't like this approach, as I'm finding.

Second, hire people who understand SOA. Those who run IT operations are valuable to the company, but may not have time to understand SOA, and thus become a bit dangerous to the effort, especially if you put them on a "committee" and give them a vote. They should be in the loop, but much further down the food chain. This means, in some instance, you're hiring consultants to play key roles. It's much cheaper in the long run, believe me.

Finally, put off the technology stuff until you know what you're doing. The first actions of these committees seem to get into a REST vs. SOAP debate, or an ESB vs. Application Server debate. Silly waists of time, and does nothing to move the enterprise closer to enjoying the agility of SOA.

I bet there is a committee in your organization, and you're having the same troubles. Well, send this blog around please.

Posted by Dave Linthicum on August 2, 2006 06:25 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •

•

• Archive •

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert