SOA

March 21, 2010

David Linthicum wrote yesterday in ebizq that cloud computing proponents seem to be avoiding the S-Word. Although most people recognize that cloud computing needs to leverage SOA, no one wants to talk about it. As Dave says, "The trouble with architecture is that it's almost as popular as the kid
in the classroom that reminds the teacher to assign homework."

I guess it's time for me to be unpopular.

Dave's assessment is spot on: Using cloud computing without a sound architectural context is dangerous. Organizations that blithely run off and deploy applications in the cloud without considering SOA principles will find themselves in worse shape than before.

SOA is not a popular topic these days. (Remember? SOA is Dead. Moldering, rotting corpses are never particularly popular.) But just because it's dead, that doesn't mean we don't need it. And SOA is particularly important to cloud computing.

If you want an application to exhibit cloudy characteristics, the traditional n-tier application architecture that we're all so comfortable with is just not going to cut it. If the application isn't designed to scale, it won't scale any better just because you've deployed it in the cloud. It all comes down to architecture:

How should you factor the application?

How do you use resources more efficiently?

How do you ensure a shared-nothing architecture?

How do you support multi-tenancy?

How do you enable dynamic lifecycle management?

How do you support consumption-based pricing?

How do you enable your cloudy application to interoperate with your terrestrial applications?

SOA's core design principles (separation of concerns, loose coupling, and encapsulation) are fundamental to cloudy design. We also need to develop new patterns to support cloudy characteristics. And this is a primary focus of our research in 2010.

If you're interested in learning more about application architecture and cloud computing, come join your peers at Catalyst this year. We're meeting in Prague on 19-22 April, and in San Diego on July 26-30.

November 21, 2009

I had the great pleasure to participate in the crafting of the SOA Manifesto last month. Thomas Erl organized the effort. Fifteen of us gathered at the second annual SOA Symposium in Rotterdam, with two others contributing remotely. It was a diverse group of people representing vendors, consultants, analysts, and journalists. All but one of us are published authors. Some members of the group are big proponents of WS-* and ESBs, while others are big proponents of REST. All of us have lots of hands-on experience with SOA. (See the bottom of the page at the SOA Manifesto site for the list of authors of the SOA Manifesto.)

Our goal is to raise awareness and realign perspectives about SOA.

We modeled the SOA Manifesto after the Agile Manifesto. The SOA Manifesto begins with a preamble, followed by a set of value statements, and ending with a set of guiding principles.

Preamble

The preamble establishes the context for the manifesto and asserts what we believe to be the intents and purposes of SOA:

Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecturethat results from applying service orientation.

We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agilityand cost effectiveness, in line with changing business needs.

A number of people have chided us for stating the obvious in the first paragraph, but our contention is that many people miss this most obvious point. Many people think that SOA happens simply by using a particular type of technology or product (e.g., WS-* or an ESB). But SOA is not about technology. SOA is entirely about design. You can't achieve service-oriented systems unless you apply the service orientation paradigm during system design.

The second paragraph speaks to the fundamental intent and purpose of SOA: to consistently, quickly, and cost-effectively deliver solutions that generate sustainable business value.

That is, while we value the items on the right, we value the items on the left more.

The bracketing qualifiers are really important here: The value statements represent prioritized values. Certainly the values expressed on the right side of each statement are important, but when faced with a hard decision between the two, designers should favor the value on the left. So let's look at each value statement.

Business value over technical strategy

This value statement asserts that the primary goal of service orientation is to generate business value. This goal trumps all other considerations, including technical strategy and adherence to the service orientation paradigm itself. In other words, you want to apply service-oriented principles when they are appropriate, but you must recognize that sometimes they are not appropriate for the needs of a specific project.

Strategic goals over project-specific benefits

This value statement asserts that system designers should always consider strategic business and technology goals when implementing a project. Decisions made for the project should not violate or subvert those strategic goals. This value statement is somewhat in conflict with the first one, and that’s intentional. Designers must balance delivering tactical value now with pursuing strategic value that’s better for the organization as a whole.

This value prioritization is missing in many organizations, and it's responsible for many SOA initiative failures. It's the "you can't see the forest for the trees" challenge. SOA requires an enterprise perspective even though implementation always occurs at a project-by-project level.

Intrinsic interoperability over custom integration

This value statement asserts that systems should be designed with interoperability in mind. Although custom integration is often required, a better approach is to build services with open, standard interfaces that support the needs of many. Keep in mind that interoperability is not simply a function of using standard protocols. I'm sure you've seen countless SOAP interoperability horror stories. Intrinsic interoperability is a function of semantic compatibility more than anything else. If you have to stick a transformation function into a communication path, you don't have intrinsic interoperability.

To some degree, I'm surprised that we were able to get the ESB vendors to agree to this value statement. If you build services that support intrinsic interoperability, you really don't need an ESB. Of course you might use an ESB as a service container (not just as a mediator), in which case you can use the ESB to expose an intrinsically interoperable service. I'll just point out, though, that RESTful services are more intrinsically interoperable than other types of services.

Shared services over specific-purpose implementations

This value statement asserts that it’s typically better to use a service that already exists rather than to build a new service that exactly matches a project’s needs.

I find this value prioritization is also missing in many organizations. Unfortunately, the impediment to using shared services is a cultural issue that's very hard to overcome. Many organizations suffer from chronic "I'm special" and "not invented here" syndromes, both of which often represent trust issues. This Geek & Poke cartoon exemplifies the problem:

You may notice that we use the term "shared" rather that "reusable" in this value statement. We had pretty strong consensus among the authors to avoid the term "reusability." We prefer "use" rather than "reuse". This value proposition primarily recommends avoiding redundancy. i.e., if you already have a service that implements the required capability, don't build another one.

Reusability is a tricky subject. A few years ago, I thought that service reuse was fundamental to the SOA value proposition. And I've certainly seen many SOA business plans that use projected savings from service reuse as the basis for their ROI. But I've backed away a bit from that focus on reuse. Designing for reuse is expensive, and many services will never be reused. And that's okay. Going back to the "strategic goals over project-specific benefits" and "intrinsic interoperability over custom integration" value statements, designers should always consider whether the services they are building could have value to the organization beyond the scope of the individual project. If so, they should design the service for reuse by concentrating on getting the granularity right and by adopting corporate standard data models that enable intrinsic interoperability. From my perspective, though, the true value of SOA comes from improved usability and maintainability of the application portfolio, as articulated in the next value statement.

Flexibility over optimization

This value statement asserts that designers should consider the needs of the future when designing systems. Optimization is clearly a desired outcome, but business requirements invariably change, and built-in flexibility reduces total cost of ownership and ultimately increases the system’s value.

Evolutionary refinement over pursuit of initial perfection

The last value statement asserts that time-to-value followed by continuous improvement is preferable to delayed deployment in pursuit of completeness and perfection. Although every designer would like to produce a perfect solution the first time, such perfection is not realistic because requirements always change. It’s better to deliver less-than-perfect value quickly and evolve the solution over time in response to real use.

Guiding Principles

We recommend that SOA practitioners consider these principles when pursuing service-orientation. I should point out that we aren't trying to define "SOA principles" here. Thomas Erl has done a great job describing the service-orientation paradigm, SOA principles, and service design patterns in his SOAbooks series. Most of these principles pertain to the business and cultural mindset required to be successful with SOA. Only a few pertain to technical design.

Respect the social and power structure of the organization.

Every SOA initiative is different, and the initiative has to work within the business and cultural constraints of the organization.

Recognize that SOA ultimately demands change on many levels.

As we assert in the preamble, the service orientation paradigm frames what you do. Adopting SOA requires changes to the way the organization funds and executes software projects. It requires new levels of collaboration across business and technical boundaries. It often requires new roles and responsibilities within the organization. It invariably requires changes and additions to governance precepts. It often requires a modification to established incentive systems to promote good behavior. Although you can start small and execute a Guerrilla SOA campaign, at some point you need to enact organizational and cultural changes to succeed.

The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.

In other words, don't bite off more than you can chew. The scope of "manageable and within meaningful boundaries" varies depending on the culture and maturity of your organization. One of the most important SOA planning efforts is analyzing and determining what those boundaries are.

Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.

In other words, SOA is something you do, not something you buy. The only way to achieve service-oriented systems is by applying service-oriented principles during system design.

SOA can be realized through a variety of technologies and standards.

In other words, SOA is not dependent on any particular set of technologies or standards. i.e., you don't have to use WS-* or an ESB to build service-oriented systems. You can build SOA systems using "plain old HTTP", CORBA, MQ, and other middleware.

Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.

Enterprise standards and policies provide the foundation for intrinsic interoperability. It doesn't so much matter which standards you use, but once you have established them, you want to convince people to use them consistently.

Pursue uniformity on the outside while allowing diversity on the inside.

We haggled quite a bit about this principle. It started out as a very simple assertion to "embrace diversity". As any large organization knows, it's extremely difficult, if not impossible, to maintain a completely homogeneous environment. Heterogeneity is a fact of life. And yet many organizations persist in trying to align their systems with a single vendor strategy. (I have many client dialogs seeking advice about "which one platform/middleware/ESB/product/etc should we use" -- and my advice is always to recognize no one product is likely to support all requirements. Most organization employ multiple platforms and products. Stop trying to fight it. Embrace diversity.)

But while heterogeneity is inevitable, it also causes usability and interoperability headaches. In order to achieve intrinsic interoperability, you want to minimize the number of standards, protocols, and data models that service consumers have to deal with. Hence the previous principle recommending a uniform set of enterprise standards and policies. So we decided the best way to articulate this principle is to present it as a strategy to balance uniformity and diversity.

"Outside" refers to the interfaces that systems and services expose to the outside world. Uniformity reduces complexity, increases usability, and promotes intrinsic interoperability. But external uniformity does not require internal uniformity. Effective use of encapsulation and abstraction allows and enables heterogeneous coexistence.

Identify services through collaboration with business and technology stakeholders.

In order to deliver services that generate business value, service designers need to get input from the people that understand the business goals of the service. Likewise business people must trust in technology people and give them the latitude to develop services in such a way that the services can best support the needs of the business as a whole. This principle reflects the sentiments of all the value statements.

Maximize service usage by considering the current and future scope of utilization.

This principle supports the 1st and 2nd value statements. The fundamental goal of SOA is to deliver business value, but don't allow tactical business requirements to impede or derail strategic business goals.

Evolve services and their organization in response to real use.

This principle supports the 1st, 5th, and 6th value statements. Only real use can verify whether a service delivers its intended value. As Moltke the Elder said, "No plan survives contact with the enemy." Inevitably, requirements evolve. Services must adapt in response to real use. In some cases, modifications occur inside the service. In other cases you may need to refactor or reorganize the services to support revised or new requirements.

Separate the different aspects of a system that change at different rates.

Separation of concerns (SoC) is a fundamental design principle of all software engineering. It is the motivation behind structured programming, object-orientation, aspect-orientation, refactoring, decomposition, and, likewise, it is the foundation of service-orientation. SoC reduces software complexity and improves comprehensibility. It promotes traceability within and across artifacts and throughout the software lifecycle. It facilitates reuse and adaptability. It also simplifies component integration. Most importantly, it improves maintainability.

Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.

This principle reflects the loose coupling SOA design principle. Loose coupling refers to the degree of flexibility between system components. Implicit dependencies increase the degree of coupling that exists between system components and therefore reduce flexibility. Publishing and abstracting dependencies reduces coupling and enables services to be moved, scaled, managed, and evolved without breaking existing connections. Loosely coupled systems eliminate the need for interoperating parties to understand a priori the internal details of each other’s IT systems.

At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.

This principle reflects the fundamental encapsulation design principle. In SOA, the fundamental unit of encapsulation is a service (hence the name, "service-orientation"). Ensuring that services are cohesive and manageable is achieved by applying service design principles such as service abstraction and service autonomy.

The phrase "at every level of abstraction" also reflects the service composability principle. That is that services can be composed to create higher-level services. The point is that designers and developers must apply the same service abstraction and service autonomy principles to composite services as they do to low-level services.

[Updated 11/22/09: fixed a couple of typos (Thanks Brian) and added the paragraph under the cartoon on "use" vs "reuse" in response to Herbjorn's comment.]

So as you can see we'll be kept too busy to check out the post-war architecture which makes Rotterdam such as fascinating place. Imagine for a moment rebuilding an entire city in the 3 decades of the 1950s-1970s. What would you come up with?

Pity we can't start building a modular cloud application architecture on such a green field site. Hybrid on-premises/off-premises applications architecture will forever be a reality for enterprises. Some organizations are unwilling or legally not permitted to host every application and its data in public or external clouds. The typical chaotic and brittle applications architecture found in most organizations means that a significant fraction of existing applications are not ready to move to the cloud.

We have a very limited number of free guest passes for the conferences still available, each valued at 1,090 Euro. If you’d like to attend the conference, leave a comment on the blog, and I'll get back to you. Once the passes are gone, we can still offer a 25% "friend of the speaker" discount.

September 16, 2009

Clients often ask us for help with their governance processes. We help them design surveys for their development teams to access the maturity of their applications and design practices with regard to sound architecture principles.

Given the problems we in the industry have had producing a formal definition, service oriented architecture (SOA) is best described as a set of design principles that support the goals of building flexible and maintainable systems. The fundamental design principles for SOA are clean separation of concerns, loose coupling, and service-orientation. These principles are not secret sauce to be poured on – if you are building systems that live and breathe these principles – you're doing SOA.

Anne Thomas Manes will publish a report later this quarter detailing the motivations behind, techniques for, and consequences of applying these SOA design principles.

How principled are you?

With any governance processes like these, clearly articulating the motivation for the principles is crucial. No professional, developers especially, like to be told to – just do it – it's good for you. Discovering the impact of abusing the design principles is not difficult to find. Think about these conversations you might have heard in the office.

When your manager asks

Can you answer these tough questions?

They're really asking about

Do you think the clients will mind if we …?

Move the server? Upgrade the interface? Re-implement in Ruby?

Loose coupling

Haven't we done this before somewhere?

Why do I have 4 customer profile applications in my call centre?

Service-orientation

How expensive is it to make changes?

What do you mean changing the UI forces us to refactor the data access layer?

Clean separation of concerns

These are just 3 examples of questions addressed by the SOA principles. If you cannot answer questions like these, you have some work to do in your service portfolio to enforce the principles more cleanly. If we continue to build systems that abuse service design principles, desired outcomes will suffer. If the service granularity is wrong or if interface and implementation concerns are badly separated, then the service will be less reusable. If business logic and infrastructure concerns are blended, developers can't make changes to systems quickly and easily. Tightly coupled systems are going to get in the way of manageability.

It's the outcomes, stupid

If SOA is about contributing to business outcomes, then measuring the value of services must start with the desired business outcomes. To be credible and repeatable, metrics must be underpinned with measurements from your runtime infrastructure and service repository. In her forthcoming paper, Anne will frame the principles and techniques with the benefits from applying each principle and with metrics for demonstrating the impact of applying or neglecting each of them. Stay tuned.

Cloud (as SOA should be) is based on trust between service providers and
consumers

Cloud (as SOA should) originates from business requirements

As far as I can tell, cloud computing *is* none of these things. It *should* be. But cloud is too nascent for such assertions. Besides, in order to achieve these characteristics in cloud-based systems, organizations have to 1- design them that way, and 2- develop the contracts and trust described. You won't achieve these characteristics automagically just by deploying a system to EC2, Force.com, or some other cloud provider.

August 12, 2009

It's been more than 7 months since I published the "SOA is Dead" post, but responses are still coming in. Most recently (yesterday), Dan Woods published an article on Forbes.com entitled "Reviving SOA". I'm pleased to see that Dan read beyond the first paragraph, and he understands the core message of my post (i.e., "SOA has been disappointing and that services should be a key focus"), he nonetheless fell into a common trap of misinterpretation, as I described in my follow-up post, "SOA Obituary: Misinterpretations and Perceptive Enrichment."

Dan falls into the first and largest camp, "Big SOA is dead, but little SOA will survive." He also has a touch of Camp 2, "REST will fix everything." He claims that "REST" is now more popular than SOAP. By "REST" I can only assume that he means plain old XML (POX) over HTTP, because I can assure you that the REST architectural style is much less understood than SOA. And a recent survey of Burton Group clients (mostly F500 companies) clearly indicates that REST is not yet a popular topic among large enterprises -- as much as I try to promote it.

Dan recommends an incremental approach to SOA: Just build services as you need them on a project-by-project basis, and at some point in the future you can go back and consolidate the services you've built and somehow derive some architectural consistency. Unfortunately, this strategy invariably leads to Just a Bunch of Web Services (JABOWS) because the future consolidation step almost never happens. The result is too many services, too many moving parts, and too many brittle connections. Systems wind up being more expensive and more fragile than ever before. #FAIL

I've only encountered one company to date that has succeeding using this method -- and I must point out that they maintained strong architectural governance of all services as they were built.

In particular, Dan misinterpreted my comment, "If you want spectacular gains, then you need to make a spectacular commitment to change." He took this as a recommendation, when it was really intended as a warning.

One of the biggest reasons that SOA "died" is due to unrealistic expectations. The hype has suggested that all you had to do was deploy an ESB and use web services and miraculously you would gain reduced costs and increased agility. The truth, though, is that architectural improvement does not come for free. It requires a concerted effort to improve the application architecture. If you aren't willing to make that concerted effort, you won't gain spectacular results.

The Bottom Line:

The highly-touted benefits of SOA derive from architectural improvement, not from any particular technology. But architecture is hard. And it requires a fair amount of organizational maturity to accomplish. Organizational maturity is a function of five organizational dynamics:

Practices: Establishing structure that helps people do what they need to do

Attempting to do SOA without also attempting to strengthen these five organizational pillars will invariably result in failure. Hence my warning: If you want a spectacularly successful SOA initiative, you must first address these organizational and cultural issues. Strengthening these organizational dynamics invariably requires a spectacular commitment to change.

July 22, 2009

Should I use WS-* or REST? Should a service provide access over HTTP, MOM, or XMPP? These are the wrong questions for architects to ask when first conceiving a service. By concentrating on how to build, we lose focus on what to build.

Debates about whether to use REST or WS-* interface styles are seductive. But, these are the wrong questions to ask first. Interface style and middleware decisions should be based on consumer requirements. The primary service design principle emphasized in a service model is maintaining a clean separation of capability ('what') from interface concerns ('how'). If we are arguing at all we should be arguing about what services to build, and why.

What is a service? This question cannot be answered in the abstract. Service modeling is an entirely contextual activity.

Despite their rich history, service design practices remain nascent. The identification and definition of sharable and reusable services is still more art than science. In this paper (Burton Group subscribers only) published today, I examine the neglected art of service modeling. When people hear "model" they immediately think of formalism, notation, and tools. My definition of service modeling is not a formal model or modeling notation. It's thinking about the answers to these questions in a repeatable way.

Can you answer these questions? Do you have places in your service development process where these questions are answered in a consistent way? Service modeling is a set of software architecture practices for providing us with a way to get at answers to these questions and document them in a way that's valuable for everyone who has a stake.

Near where I live, in Dublin, is an extensive park called St. Anne's Park. It's part of what was the Guinness estate (yes, that Guinness!). This is a Greek Temple, built in the park as tea house by the Guinness family. It’s has very ornate mosaics on the floor, and is almost perfect classical design.

But, it's a Folly. Follies are buildings, or parts of buildings that have no purpose other than as an ornament; they are purpose-built as ornaments; they are often eccentric in design or construction; there is often an element of fakery in their construction.

The Guinness family built this because they were wealthy, just because they could. We can't afford to do that in our organizations any more. What we build must be relevant, driven by the right business context, and play its part in a portfolio. As you can see from its state of repair, there's no great motivation to maintain the tea house. It’s not valuable any more, if it ever was...

Put simply, if you create services without a service model, then you are creating bespoke application integration interfaces and not doing service oriented architecture. If context is not driving you to create the right services, then they are most likely not adding value to your applications architecture, they are making it worse.

July 16, 2009

"Members of OASIS, OMG, and The Open Group announce the publication of a new white paper, 'Navigating the SOA Open Standards Landscape Around Architecture.' The paper was produced to help the SOA community at large navigate the myriad of overlapping technical products produced by these organizations with specific emphasis on the “A” in SOA; i.e., Architecture.

This joint white paper explains and positions standards for SOA reference models, ontologies, reference architectures, maturity models, modeling languages, and governance. It outlines where the works are similar, highlights the strengths of each body of work, and touches on how the work can be used together in complementary ways. It is also meant as a guide to users of these specifications for selecting the technical products most appropriate for their needs, consistent with where they are today and where they plan to head on their SOA journeys."