Real World SOA | David Linthicum | March 2008

MORE ENTRIES

March 2008

March 27, 2008 | Comments: (0)

Joe McKendrick does a great job in defining the relationship between the "Web 2.0" and SOA in his latest posting.

"There's no question that SOA has been a tough sell in many organizations. Conversely, the response to Web 2.0 has been almost a cult-like following -- many end users can't get enough of these online tools.

How can SOA proponents glom onto some of this enthusiasm? Some experts say that the lightweight, user-friendly techniques seen in the Web 2.0 experience can serve as SOA's best selling tool. Some even say that eventually, the two worlds may even blend to the point where they are indistinguishable."

Of course, if you've been reading this blog and listening to the Podcast you already know that I've been waving my hands for years about the synergy between the emerging Web and SOA. No brainier if you ask me, considering the number of services that are now available on the Web, and the value of leveraging those services within the enterprise, using SOA approaches.

It's actually surprising to me that people are just getting this now. Think about this logically. You have a collection of services, and other resources, accessible over the Web and you're able to combine those services into solutions (e.g., Mashups). Better yet, you're able to recombine those services into new solutions as your needs change, and again, and again…you get the idea. That sounds like an architectural pattern to me, providing the advantage of agility.

My colleague Ron Schmelzer, of course, has his own opinions on this topic…

"Web services and SOA are two very different things, meant to serve different purposes."

"The concept of SOA actually predates Web services by at least five or six years. The main proponents of service oriented architecture at that time created architecture around CORBA. The use of Web services technology is only appropriate for certain circumstances; it's not appropriate for all uses of service oriented architecture. For example, I wouldn't want a mobile device sitting on a network consuming heavy Web service and protocols."

Actually, Ron is correct in that SOA is architecture, and a collection of Web services is not architecture. However, I think the emerging Web can be more than just a bunch of Web services, indeed we're moving quickly to a time when most of the major architectural patterns, including SOA, can exist on the emerging Web taking advantage of all of the resources that the Web has to offer. It's evolving now, and I'm happy to call it a "Global SOA" when indeed it is a "Global SOA." We're getting there, and I love it.

Posted by Dave Linthicum on March 27, 2008 12:46 PM

March 25, 2008 | Comments: (0)

SOA is growing

Download file

Posted by Dave Linthicum on March 25, 2008 06:46 AM

March 24, 2008 | Comments: (0)

Is SOA green?

You would think the "environmental movement" was just invented with all of the talk about "global warming" and "carbon footprints." What's in style now is to be "green" or putting conservation into practice in your daily life. No, I'm not going to focus on this issue, that's a topic for many other blogs, but I would like to look at how SOA relates to conservation, or being green.

Truth-be-told, I'm not green by nature; however I am a business man. Thus, with gas approaching four bucks a gallon, I made the shift from an SUV that get's 11 MPG to a crossover that gets 30 MPG. I'm not ready for a Hybrid yet, just seems too conformist if you ask me.

So, if everything is about conservation, what does SOA have to offer? Everything really. Let's face it millions of dollars are tossed away everyday on wasted motion in the world of business…products that require more resources than they should during the manufacturing process, excessive use of the transportation and shipping systems, and of course the continued use of too much paper.

The fact of the matter is that the more efficient a business is, the fewer resources, natural and otherwise it will consume. Thus, the better the business is automated, and business processes optimized, the more efficient it will be. The primary of objective of an SOA is both efficiency and agility through architectural rejuvenation, we've beat that to death here.

So, is SOA green? Perhaps, considering that businesses that practice both good IT architecture, including SOA, will be rewarded with business processes that are both optimized and changeable to align with the business. Thus, anything that the business does will require the fewest amount of resources and dollars, and you can call that green no matter if you mean saving the environment or cash in the bank…both are very good.

Posted by Dave Linthicum on March 24, 2008 10:16 AM

March 21, 2008 | Comments: (0)

The federal government needs to understand SOA

The federal government is the Fortune 1 when it comes to leveraging and consuming technology. However, the use of that technology in the most productive ways continues to be a challenge. Lately, the federal government has been serious about getting their own IT house in order, focusing more on architecture, common issues, and thus SOA.

Of course, the use of SOA varies greatly from government organization to organization, and where some areas of the government are making some headway, others are catching up, or not yet starting.

So, what steps do you need to take to make SOA work for the federal government? Pretty easy, actually, and the focus of my tutorial occurring at FOSE on March 31^st, where I plan on taking the typical government IT professional through the life cycle of an SOA, and show them specifically where they can jump on board.

An agile government is an effective government, if you ask me.

Posted by Dave Linthicum on March 21, 2008 07:24 AM

March 20, 2008 | Comments: (0)

It's all about the business case

I spotted this article, by Rich Seeley, outlining some recent findings from Forester, showing that SOA is growing steadily all over the world.

"In 2005, the survey found 53 percent of enterprises were 'using or planning to use SOA.' By 2006, that number had grown to 62 percent, and in 2007 it reached 66 percent. More importantly for the theme of the latest survey, enterprises with an 'enterprise level strategy and commitment to SOA' went from 18 percent in 2005, to 22 percent in 2006, and 26 percent in 2007.

In an equally telling statistic, the percentage of enterprises reporting that they were not pursuing SOA and had no immediate plans to do so fell from a high of 47 percent in 2005, to 33 percent in 2007."

The fact of the matter is that the notion and practice of SOA is expanding, but every so slowly when compared to other technology trends. This is a good thing, if you ask me, considering the complexity and scope of SOA, and the good or bad impact it can have on a business.

What's driving this movement is not as much about the technology, but the business benefit, as Forester is finding.

"The survey also found that the business benefits of SOA are coming to the forefront and helping drive adoption."

However, where people are selling the reuse concept of SOA, reuse is typically not going to be the business driver. We've hit upon that topic many times on this blog and Podcast.

"He warns that the often touted reuse benefit of SOA is a tricky topic, because the values of reuse are not always clear and first glance."

Good news overall. First that SOA is growing, and second that the business case is driving it. That's typically healthy when considering how we followed, and them dumped a number of technological trends in the past. However, SOA is far more than a trend…it's an architecture and should have the proper amount of strategic consideration within the enterprise. Hopefully we're getting there.

Posted by Dave Linthicum on March 20, 2008 06:37 AM

March 18, 2008 | Comments: (0)

Improving on architecture

Download file

Posted by Dave Linthicum on March 18, 2008 01:46 PM

March 14, 2008 | Comments: (0)

Considering services and orchestration

The best way to consider both notions of service and orchestration (and process integration in general) is to think of them as independent layers, where the process layer is the calling application to the services to extract both data and behavior needed to form cohesive orchestrations. This interaction allows the architect and the developer to place certain things into certain domains. The orchestrations that define the way the services are leveraged, and the services that…well…provide service.

Orchestration is a necessity if you build a SOA, intra- or inter-organization. It's the layer that creates business solutions from the vast array of services and information flows found in new and existing systems. Orchestration is a godlike control mechanism that's able to put our SOA to work, as well as provide a point of control. Orchestration layers allow you to change the way your business functions, as needed, and to define or redefine any business process on-the-fly.

For our purposes we can define orchestration as a standards-based mechanism that defines how web services work together, including business logic, sequencing, exception handling, and process decomposition, including service and process reuse. Orchestrations may span a few internal systems, systems between organizations, or both. Moreover, orchestrations are long-running, multi-step transactions, almost always controlled by one business party, and are loosely coupled and asynchronous in nature.

Orchestration encapsulates and leverages services, binding them together to form higher level processes and composite services. Indeed, orchestrations themselves should become services, and may be leveraged as services.

Here are a few things to consider:

A single instance of orchestration typically spans many instances of service- and information-oriented points of integration, perhaps many domains and even organizations. Thus, you typically have one orchestration for many services.
Most orchestrations leverage public standards such as BPEL. However, there are a few competing standards, such as process and workflow standards, and technology that can do very much the same job…binding services into processes to form solutions. Thus, when considering the process/orchestration solutions, you have many to choose from that provide process-based control, using or not using BPEL.
Orchestrations may be public, or available to everyone, private, available to just the owner, and shared, for supply chain integration scenarios. Thus, orchestrations can span businesses, supporting supply chain integration and other B2B activities.
Orchestrations are usually driven from a single party; they are not always collaborative in nature.
Orchestrations themselves may become services available for other services or orchestrations (as mentioned above).
Orchestration defines a meta-application, of sorts, that has visibility into many encapsulated services as well as application information that may be bound to those services.
Orchestration is independent of the services they are leveraging. Changes can be made to the orchestration without having to force changes to the services. In other words, this architecture is a loosely coupled, services to orchestrations.
Orchestrations may be decomposable down to base processes, and finally services. The hierarchy further provides architectural control to the architect or the developer in support of the business solution they are automating.
Orchestration, in context to a SOA, is strategic, leveraging business rules to determine how systems should interact and better leverage the business value from each system through a common abstract business model.

Posted by Dave Linthicum on March 14, 2008 07:05 AM

March 11, 2008 | Comments: (0)

Do you have the political will for SOA?

Mike Kavis has a good take on the role of the Enterprise Architect in the world of SOA. Mike is one.

Responding to my last post.

"Dave's point 'Somebody needs to have the political will to figure out a long term solution' is what I am referring to as 'fighting the good fight'. As enterprise architects, chief architects, CIOs, and CTOs, we owe it to our respective companies to deliver value, efficiencies, and enable our business partners to achieve their goals. Too often, IT shops have become bogged down in keeping the lights on because they always take the quick and dirty route to solving problems. Always remember, the dirty hangs around long after the quick is gone. It is time to fight the good fight and build an architecture that allows your IT shop to be responsive to the business (agile) while building a sustainable architecture that supports both short and long term needs."

So, what does an architect need? Mike adds some color:

"Emotional Intelligence - ability to perceive, assess, and manage the emotions of yourself or others.

Leadership - ability to affect human behavior to accomplish a mission or goal

Effectively Communicate - ability to clearly articulate (verbal and written) one's message. Includes ability to persuade, negotiate, articulate, sell, and others.

Intelligence - ability to learn and retain information about new technologies, processes, and solutions.

Problem Solving - Find solutions to complex problems, both technical and non-technical

Vision/Strategic - Ability to predict future patterns and plan accordingly. Create roadmaps and action plans for accomplishing goals."

I can't argue with that, as long as there is some technical knowledge that's in there as well. Architects have the unenviable role of meshing people, with technology, with a business. That's going to take a unique person to be successful longer term, I've seen very few people who live up to those expectations. Indeed, they are either business people, people people, or technology people. Never all of the above.

Posted by Dave Linthicum on March 11, 2008 04:19 AM

March 11, 2008 | Comments: (0)

Retro podcast: Web 2.0 interview from 2006

Download file

Posted by Dave Linthicum on March 11, 2008 03:54 AM

March 09, 2008 | Comments: (0)

Why enterprise architects continue to fall short with SOA…and Enterprise Architecture

If you've been reading this Blog and listening to my Podcasts, you know that I've been calling SOA what SOA is…an architectural pattern, and in many instances a vital component of a healthy enterprise architecture. Indeed, I've provided some keynote talks around this very topic to about half-a-dozen enterprise architecture conferences to date. However, generally speaking, the enterprise architects out there continue not to get SOA, and continue to do a poor to average job creating enterprise architectures that…well…support their enterprise.

By the way, those of you who will respond to this post and tell me that you're doing well with your architecture, that's fine. Unfortunately, dozens of you can be an exception to my observations, and it still does not mean I'm wrong here. This is a systemic problem.

Here are the issues:

Don't understand SOA. The largest issue is that enterprise architects out there continue to not get SOA. Either they just don't bother, or want the definition of SOA to fit some preconceived and incorrect notion in their minds. Are you listening…guys who use "SOA" and "ESB" interchangeable?

Don't understand their own issues. The other problem is that many enterprise architects don't understand their own issues. Most can't tell you the cost of inefficiencies within their existing IT infrastructure and enterprise architecture, any value they would get from reuse, and any metrics around the value of agility within the enterprise. In some instances there is no central record/artifacts around data semantics, APIs, processes, workflow, etc.. No clear understanding of what the current issues are, and no notion as to how to correct them over time.

Fear change. If things are bad, than change is typically good. Unfortunately, change also means risk, and risk is something people typically don't like. The fact of the matter is that people are rewarded for maintaining more so than improving, and thus how many of the enterprise architectures out there are now layers upon layers of tactical one-off solutions designed to "keep things going a few more years." Somebody needs to have the political will to figure out a long term solution, using sound enterprise architecture approaches, including SOA.

Unfortunately, I'm not sure that guys like me shining a light on these shortcomings will have much impact. I think it's going to take some well published disasters that almost kill a company or two before the powers that be understand the real problem here. Hopefully, a few of you will be more proactive.

Posted by Dave Linthicum on March 9, 2008 12:31 PM

March 06, 2008 | Comments: (0)

Reusing the Reuse Topic

Joe McKendrick had some good ideas around my thoughts on reuse, and some good original insights as well.

"However, there are three sticky questions around reuse: First, should reuse be a goal in itself, or does it play more of a supporting role to more business-focused higher-level benefits? Is it like trying to measure the number of times employees open up Excel spreadsheets through the day, versus measuring the insights and actions they take as a result of the data they get out of their spreadsheets?"

I think reuse should be a goal, and clearly we've had that on our radar in IT for some time. However, to Joe's point, the core benefit is the value of reusing, not that fact that you reuse. There is a difference.

"The second question is even more vexing: is reuse even essential at all to SOA success? Suppose there are services that are only used by one application each? These services may offer streamlined interfaces that provide independence from the application underneath, saving countless hours of toil and disruption when the app changes."

I think SOA can still have value without a significant amount of reuse. That's my point, that we're too focused on reuse as a metric when it clearly has secondary value.

"Third, suppose business units across the enterprise go wild with reuse, to the point where it gets difficult to track who is using what and how often? The SOA appears to be a raging success, but how is it helping the business? Is it amounting to anything? Is so, how can that be measured?"

This is the core issue around the need for SOA governance, best practices, and technology. I agree that we need to measure reuse, no matter if it's occurring or not. I'm a big advocate of centralized control and management, albeit the typically enterprise is not. However, based on past experiences, I suspect we'll not get to this kind of "mass reuse" anytime soon, so I would not worry about it.

Posted by Dave Linthicum on March 6, 2008 09:21 AM

March 05, 2008 | Comments: (0)

Defining Types of Services

From an e-mail: "Do all services share the same patterns?"

In the world of SOA, there are two types of services: data services, and transactional services, and each requires a different approach to designing, building, testing, and governing.

Data services, as the name implies, means that the service typically provides data abstraction representing a physical database or databases, and thus is more data-oriented and should be tested as such. You need to monitor the consumption of information from the physical data stores, the re-mapping of the data into the new schema, and the new structure provided to the other services or orchestration layer that is interacting with the data service.

Transactional services, as the name implies, deal with data and are really the core services providing application behavior and functionality. Thus, while you do need to monitor information flowing through these services, and the changes made to that information, you also need to pay attention to the processing, and test those features as well.

Of course it's not that simple. There are also hybrids of these services, such as abstracted and composite services, which are services unto themselves, but are made up of other services, either transactional or data services. Moreover, there are sub-patterns around services we can also identify. Perhaps a topic for another posting.

Keep the e-mail coming. Make sure to put "Real World SOA" in the subject.

Posted by Dave Linthicum on March 5, 2008 04:52 AM

March 04, 2008 | Comments: (0)

What’s Neglected When Testing Services?

People are forgetting a few things when testing services.

First and foremost, services should be tested for reuse (reusability). Services become a part of any number of other applications, and thus must be tested so they properly provide behavior and information, but not be application or technology specific. This is a difficult paradigm for many developers since custom one-off software that digs deeply into native features is what they've been doing for most of their careers. Thus, the patterns must be applicable to more than a single problem domain, or application, or standard, meaning you must have use for your reusable service and it must be in good working order.

To test for reusability you must create a list of candidate uses for the service. For instance, a shipping service that plugs into accounting, inventory, and sales systems. Then, the service should be consumed by the client, either through a real application (in a testing domain) or a simulator, and the results noted.

In addition, the service should be tested for heterogeneity. Web services should be built and tested so that there are no calls to native interfaces or platforms. This is due to the fact that a service, say, one built on Linux, may be leveraged by applications on Windows, Macs, and even mainframes. Those that leverage your service should do so without regard for how it was created, and should be completely platform independent. The approach to testing this is rather obvious; simply consume the service on several different platforms, and note any calls to the native subsystems.

You should also test for abstraction. Abstraction allows access to services from multiple, simultaneous consumers; hiding technology details from the service developer. The use of abstraction is required to get around the many protocols, data access layers, and even security mechanisms that may be in place, thus hiding these very different technologies behind a layer that can emulate a single layer of abstraction.

Abstraction is tested effectively by doing, which means implementing instances and then testing the results. Regression and integration testing is the best approach, from the highest to the lowest layers of abstraction.

When we build or design services we need to test for aggregation. Many services will become parts of other services, and thus composite services leveraged by an application. You must consider this in their design. For instance, a customer validation service may be part of a customer processing service, which is part of the inventory control systems. Aggregations are clusters of services bound together to create a solution, and should be tested holistically through integration testing procedures.

Posted by Dave Linthicum on March 4, 2008 05:04 AM

March 04, 2008 | Comments: (0)

Do You Need a SOA Enforcer?

Download file

Posted by Dave Linthicum on March 4, 2008 04:10 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •