Latest News from Jason Bloomberg

The Four Stages of SOA Governance

Fri, 13 Nov 2009 17:45:00 EST

For several years now, ZapThink has spoken about SOA Governance "in the narrow" vs. SOA governance "in the broad." SOA governance in the narrow refers to governance of the SOA initiative, and focuses primarily on the Service lifecycle. When vendors try to sell you SOA governance gear, they're typically talking about SOA governance in the narrow. SOA governance in the broad, in contrast, refers to IT governance in the SOA context. In other words, how will SOA help with IT governance (and by extension, corporate governance) once your SOA initiative is up and running?

Are Services Nouns or Verbs?

Wed, 14 Oct 2009 12:45:00 EDT

Should Services be nouns or verbs? It's possible to design Services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?

The Critical Link between SOA and BPM: Process Isomorphism

Fri, 18 Sep 2009 04:45:00 EDT

There are plenty of Enterprise Architects who see the connection between Business Process Management and Service-Oriented Architecture initiatives, and who have pulled them together into "BPM enabled by SOA" efforts. This synergy, however, is not automatic, and requires some hard work both among the people focusing on optimizing business processes to better meet changing business needs as well as the team looking to build composable Business Services that support the business agility and business empowerment drivers for their SOA initiatives. ZapThink has worked with many such organizations, and over time a distinct best practice pattern has emerged, one that is both fundamental as well as subtle, and as a result, has fallen through the cracks of compendia of SOA patterns: the Process Isomorphism pattern. Understanding this pattern and how to apply it can help organizations pull their BPM and SOA efforts together, and even more importantly, improve the alignment of their SOA initiatives with core business drivers.

Why Today is a Perfect Time for No-Platform SOA

Fri, 04 Sep 2009 07:00:00 EDT

The most dangerous pitfall of the SOA platform-centric approach to SOA: because it depends upon integration middleware, it succumbs to the issues with middleware that SOA was meant to address, namely the lack of agility and the increasing costs of integration over time. Basically, you'll eventually need more middleware to get your various ESBs to interoperate or federate with each other. Now, it's possible to implement SOA in this manner, but if you're unable to achieve either the business agility or cost savings benefits of the new architecture, then why bother?

Business Agility as an Emergent Property of SOA

Thu, 27 Aug 2009 06:00:00 EDT

In the SOA context, we focus on building and maintaining the Business Service abstraction, which supports inherently unpredictable behavior as the business composes Services to support fundamentally dynamic business processes. Essentially, with SOA we're building for change, while with Traditional Systems Engineering, we're building for stability. The problem with stability, of course, is it only takes the business so far -- if the organization requires business agility, then they're much better off implementing SOA.

Best Effort SOA and the SOA Quality Star

Thu, 20 Aug 2009 20:25:00 EDT

The agility requirement for SOA vastly complicates the quality challenge, because functional and performance testing aren't sufficient to ensure conformance of the SOA implementation with the business's agility requirement. In essence, the business isn't simply asking the technology team to build something with capabilities A, B, and C, but is also asking them to build something flexible enough to meet future requirements as well -- even though those requirements aren't yet defined.

Net-Centricity: SOA in Battle

Thu, 20 Aug 2009 05:45:00 EDT

As the DoD and their contractors hammered out the details of Net-Centricity, it became increasingly clear that Net-Centricity required a broad, architectural approach to achieving agile information sharing in the context of a complex, siloed organization. At that point, SOA entered the Net-Centricity picture, providing essential best practices for sharing information resources to support business process needs. In the military context, such business processes are operational processes, where the operation at hand might be fueling airplanes or deploying ground troops or spying on suspected terrorists with a satellite. When battlefield commanders say that they want the warfighting resources at their disposal to be available as needed to achieve their mission objectives, they are essentially requiring a Service-Oriented approach to Net-Centricity.

Service Semiotics and the SOA Illusion

Mon, 17 Aug 2009 08:15:00 EDT

Visual representations of Services, as well as the composition and consumption of those Services, are becoming the key to many SOA success stories. Without a visual component you can show business users, SOA becomes abstruse; furthermore, as organizations leverage Web 2.0 principles to build mashups, the visualization aspect of the Web 2.0 value proposition becomes a driving force for SOA. Understanding how Services look, therefore, is a critical part of understanding how they provide value.

The Buckaroo Banzai Effect: Location Independence, SOA, and the Cloud

Mon, 10 Aug 2009 10:45:00 EDT

Now that Service-Oriented Architecture (SOA) is finally becoming mainstream, an increasing number of people are asking us what comes after SOA. If SOA is one step in the evolution of distributed computing, the reasoning goes, then something is bound to be next in line. Furthermore, just as SOA built upon Web architectures, client/server, and the rest of what are now today's legacy technologies, so too will this "Next Big Thing" (for want of a name) build upon, rather than replace SOA.

Avoid Getting Lost on the (Enterprise Service) Bus

Thu, 30 Jul 2009 18:30:00 EDT

While purchasing an ESB too early in a SOA project does substantially increase your risk of failure, all is not lost. After all, you're not alone; this mistake is one of the most prevalent SOA snafus in IT shops around the world today, and not all of those projects end up as failures. Many of today's ESBs are now mature products, and can be an important part of a fully functional SOA implementation. Understanding the risks that buying an ESB too early in a SOA initiative presents, and dealing with those risks proactively, can turn a bad situation around and get your SOA initiative back on the right track.

The SOA Marketing Paradox and the Wizard of Oz

Thu, 23 Jul 2009 07:15:00 EDT

Service-Oriented Architecture (SOA) presents a challenge to software marketing people like none other in recent history. On the one hand, SOA has been the top enterprise software bandwagon to jump on for the last four years or so, but on the other hand, many vendors have struggled to tell the proper SOA story for their products in a way that leads to increased sales and happy customers. The reason SOA presents such a formidable challenge is at once both subtle and obvious. After all, SOA is architecture -- it is a set of best practices enterprises follow to organize their IT resources to meet the needs of the business. SOA, however, is not, and never will be, a set of product features. And therein lies the rub. How do you position your product as a SOA product when SOA consists of best practices, not product features?

Is Your SOA Hammer Looking for a Nail?

Wed, 22 Jul 2009 12:30:00 EDT

ZapThink considers the SOA business case as an essential SOA artifact. Architects must have a clear picture of the business motivations for SOA, not only at the beginning of the initiative, but also as the architecture rolls out. Nevertheless, there is still frequently a disconnect between the business problems and the SOA approach. The challenge here is that the architects -- or more broadly, the entire SOA team -- are only one part of the bigger picture, especially in large organizations. In the enterprise context, how the business asks for IT capabilities in the broad sense is often at the root of the issue.

The Concrete Abstraction of the Business Service

Sat, 18 Jul 2009 23:00:00 EDT

Loose coupling presents architectural challenges that are at the heart of planning and implementing the SOA infrastructure. Building the Service abstraction presents a simplified representation to the business but requires additional efforts under the covers to make that abstraction a concrete reality. This is the work of SOA: implementing and maintaining loosely coupled business Services that are at the core of any successful SOA implementation.

Cloud Governance: Something Old, Something New, Something Borrowed…

Wed, 15 Jul 2009 10:15:00 EDT

Cloud availability. Cloud security. Erosion of data integrity. Data replication and consistency issues. Potential loss of privacy. Lack of auditing and logging visibility. Potential for regulatory violations. Application sprawl & dependencies. Inappropriate usage of Services. Difficulty in managing intra-Cloud, inter-Cloud, and Cloud and non-Cloud interactions and resources. Do any of these issues sound familiar? To address these concerns, we have to return to governance. The above issues are primarily, if not exclusively, governance concerns. Thankfully, in many ways, we can apply what we’ve already learned, implemented, and invested in SOA Governance directly to issues of Cloud Governance. However, SOA and Cloud, while complementary, are not equivalent concepts. There are a wide range of patterns and usage considerations that are either new to the SOA Governance picture or ones that we were able to gloss over. To make Cloud computing a success, we need to make Cloud governance a success. So, what can we apply from our existing SOA governance knowledge, and what new things do companies need to consider?

SOA: Integration vs. Business Process?

Mon, 13 Jul 2009 11:15:00 EDT

Ever since ZapThink coined the term "Service Oriented Integration" (SOI) back in 2002, there's been unceasing confusion on just how Service-Oriented Architecture (SOA) and integration relate to one another. Several recent blog posts have refocused attention on this confusion, including ones from Anne Manes, Todd Biske and Loraine Lawson. Perhaps some of the confusion is over the definition of the SOI term, and what distinguishes SOI from Web Services-based integration, if anything. But the bigger controversy is over the larger question as to SOA's fundamental purpose: is SOA's purpose to solve integration problems, or is it more of a business transformation approach centered on implementing agile business processes?

Best Practices for SOA: Building a Data Services Layer

Mon, 23 Jun 2008 12:30:00 EDT

These days nearly every sizable organization has either implemented some form of SOA or has it on their roadmap. They quickly find that SOA efforts tend to expand like spider webs, eventually touching every corner of IT as well as the business itself. Due to the vital role that data plays both in business and systems operations, database architects, information specialists, data integration experts, and anyone responsible for data persistence in an organization are increasingly being called on to contribute to their organization's SOA initiatives - whether or not this was intended at the onset.