Reaching the SOA Tipping Point

The core benefits that Service-Oriented Architecture (SOA) promises–cost reduction, increased business visibility, business empowerment, and greater business agility–are becoming increasingly understood and sought after, but the fact remains that many organizations are still struggling with various challenges in the early stages of their SOA initiatives. Many such challenges are organizational and political, and as a result, many well-meaning SOA initiatives have devolved into stopgap measures and political compromises. Such projects risk failure, delays, and cancellations.

To avoid such pitfalls, it’s increasingly important for organizations to take a pragmatic approach to SOA adoption that achieves business goals under the radar, building momentum and business value iteratively. For architects who are fed up with the status quo of IT and can see the big picture of the SOA value proposition for their organizations, taking such a pragmatic approach can be the most effective way to achieve the SOA tipping point, where the organization as a whole comes to accept and value SOA as mainstream across their organizations.

Practical SOA: Insurance

Presentations from ZapThink’s Practical SOA for Insurance event on May 16, 2008. Presented as a 232-slide PowerPoint in pdf format (large file). Agenda as follows:

Leveraging SOA for Agile Business Processes

Enterprises around the world are facing a momentous transformation, as they move away from traditional, inflexible approaches to leveraging information technology (IT) resources to a more agile way that helps to improve business process. This transition from an aggegration-centric view of technology that leads to brittle assemblages of heterogeneous assets to the composition-centric view that positions IT resources as flexible services that the business can compose together to support and manage flexible processes heralds a new era of value to organizations. Underpinning this transition is the move to Service-Oriented Architecture (SOA), which provides best practices for organizing IT resources to enable organizations to better leverage business change.

More on the SOA Governance Thing

I had a few good responses to my blog post on SOA Governance.

The purpose of the post was to define the patterns found in SOA Governance tools, and it is indeed okay to define those patterns. Not sure it’s “dangerous,” just adds clarity for those looking at these tools. In essence, that was the purpose of the post. I should have been clearer about that.

Read more at: InfoWorld

Opportunity Knocks, SOA Consultants Answer

Last year, ZapThink’s Ron Schmelzer sounded warning bells about a looming enterprise architect “drought” which could derail many SOA efforts. He noted that there “is a significant demand in the marketplace for experienced SOA talent,” and “a burgeoning of SOA consulting companies that offer kick-start approaches to SOA in which they supply the experienced architects and their customers supply the heavy-lift labor to implement the services.”

Read more at: SOA in Action Blog

ZapThink Podcast: Practical SOA Frankfurt Sneak Peek

Special ZapThink “Sneak Preview” Podcast for January 8, 2008 features:

Ron Schmelzer, Managing Partner, ZapThink

Ingo Arnold, Enterprise Systems Architect, Novartis Pharma AG

Wolfgang Otto, Principal Systems Engineer, BEA Systems

Florian Mösch, Vice President Enterprise Integration & Architecture, T-Mobile Deutschland GmbH

Jason English, iTKO, iTKO

Dr. Waldemar Lohrer, Senior Berater, Swiss Life

Tim Hall, SOA Center Product Management, Hewlett-Packard

Lars Drexler, VP Sales Enablement, Software AG

Listen to this Podcast and you will get a “Sneak Peek” at what all the presenters will be speaking about at our Practical SOA event in Frankfurt, Germany, on January 15, 2008.

How to Define a Business Service

How to define a Business service is a pervasive and critical question that is essential to the success of any Service Oriented Architecture (SOA) initiative. SOA projects can consist of too many moving parts causing confusion on what to use, reuse, or leverage. It then becomes the challenge of the architect to reduce this confusion by identifying the proper best practices for defining Services properly to meet the business goals set out for them.

Such practices include a variety of approaches. Architects can define a Service:

• in the context of business processes
• in the context of existing assets leveraging the business, information that the Service is expected to send or receive
• in an iterative fashion that delivers business value and decreases risk.

Combined with SOA governance processes that alleviate the challenges with managing too many moving parts, the architect will have the necessary best practices to manage the art and science of Service definition and accelerate SOA adoption.

The Next SOA Vendor to Be Acquired!

This blog asks “Who are the SOA centric companies that have not yet been acquired?” as if they are the ugly ducklings of the SOA dating game no one wants to marry.

Joe McKendrick also writes about this subject in his April 19, 2007 dated blog entry entitled “The incredible shrinking SOA vendor pool: good or bad?” referring to David Linthicum’s opinions: “Dave Linthicum, who has been involved in plenty of IT vendor acquisitions, has been keeping tabs on the churning SOA vendor space, and estimates that anywhere between three to four dozen SOA specialty vendors have been acquired in just the last couple of years. Isn’t that a good thing? For the investors in these companies, yes. But for SOA innovation, no, Dave says. In fact, we may be losing our competitive edge in SOA as a result.”

Read more at: Sys-Con

SOA Implementation Best Practices

The role of SOA is to provide an architectural approach that supports an organization’s ability to support ongoing business change in the face of a heterogeneous environment. However, since SOA does not introduce a new programming language or runtime environment, organizations must implement code that underpins and exposes a Service interface somehow. Since implementation matters to computers as much as architecture matters to people, it makes sense to consider the runtime environment of the implementation to be a good place to coordinate Service interactions.

When looking at the technology buying patterns in the world of SOA, there is one common thread. The influence of the larger SOA vendors is very much a force in the market today. Within this context, and given continued consolidation, confusion, and change in the SOA marketplace, organizations should make a careful evaluation of the various vendor offerings that support SOA implementations. The consolidation of SOA implementation capabilities has yielded a collection of vendors offering the new solution stack: the “SOA Platform”.

When comparing vendors, it is important to verify how their products and services address both parts of the lifecycle. If the vendor’s own products or services address the full lifecycle, what is their strategy for interoperating with other vendors whose products or services fill the gap? Are vendor platforms just an amalgam of acquired, partnered, and separately developed technologies, or do they represent a cohesive collection of agile SOA infrastructure that supports the widest range of SOA capabilities? This report aims to identify SOA platform vendors and help make the evaluation using the above criteria.

Defining a Business Service

Pointers for how to define a business Service, including a discussion of Service granularity and the business Service abstraction. Presents a clear distinction among Service implementation, Service interface and abstracted Business Service.

Presented at a Software AG Webinar on October 24, 2007.

16-slide PowerPoint in pdf format.