Category: services

(micro-)service oriented architecture

CIO as dinosaur

From Baseline/CIO Insight, a report on emerging technologies; specifically, a survey of CIOs of what technologies that they’re actually using. Some results that I find to show the incredible short-sightedness of many corporate CIOs is the percentage who find the following technologies “of no interest/not on the radar”:

  • SaaS, 32%. How could this number of CIOs possibly have no interest in SaaS? Only one answer comes to mind: empire building.
  • SOA, 30%. The percentage of CIOs who prefer to remain mired in legacy linguine.
  • AJAX, 46% and RSS, 38%. How to they plan to deliver information, both interactively and via publication, in the future? This isn’t just an externally-facing issue; in large organizations, these technologies are equally important for serving it up to internal users.
  • Social networking, including tagging, 51%. Although other things were mentioned in this category, I see tagging as the key contributor to a corporate environment here. How long will it be before all ECM systems have tagging as a standard feature? When will CIOs stop characterizing this as “allowing the lunatics to run the asylum” and just put the right categorization tools in the hands of their users?
  • Wikis, 46%. Okay, I get why a lot of companies are still uncomfortable with blogs. But wikis for collaboration make a lot more sense than clogging up everyone’s email with multiple out-of-date copies of a Word file that everyone is trying to update at the same time. It’s only a matter of time before Microsoft adds wiki capabilities to SharePoint (if they haven’t already), at which time everyone will be using wikis below the CIO’s radar. David Berlind posted yesterday about how many IT leaders have never even heard of wikis, which is likely where the “not on the radar” is really coming from.

There are a lot of other equally shocking stats about just how far behind corporate CIOs are in their thinking. Many of my clients are large financial institutions, so I suppose that I shouldn’t be that shocked: if I polled them directly about these same issues, I’d likely get similar results. Unfortunately, that doesn’t give me much hope that these organizations are going to become a lot more efficient or offer better services to their customers any time soon.

On the BPM front, only 21% show as “deployed”, 19% “testing/piloting”, 27% “evaluating/tracking” and 32% “no interest/not on the radar”.

Update: I just saw this post on why AJAX and RSS matter for in-house user interfaces, particularly for BPM.

Update: Robert Scoble reports that wikis will, indeed, be in Sharepoint 2007. The meteor has landed, you guys can all just head for the tar pits.

SOA 2-point-uh-oh

The first bit of David Linthicum‘s podcast today covers the SOA 2.0 naming nonsense, calling it “disingenuous” and a “land grab”, and pointing out that it will cause more confusion. Yesterday, I linked to Macehiter Ward-Dutton’s Stop the Madness petition to protest the use of the term SOA 2.0. Since then, Loek Bakker and I have been having a conversation about it.

To quote a comment that I put on Loek’s post, I’m assuming that the two Neils are being a bit tongue-in-cheek with the petition, and are using it more to raise awareness of the silliness of versioning a concept. Regardless, head over there and sign it as a strike against meaningless marketing-enabled terminology worldwide!

Update: I forgot to link to James Governor’s post, which links to several others that share this opinion on SOA 2.0, and on to their links, and so on.

SOA in OMG newsletter

The Spring OMG newsletter is available online (direct link to PDF) with a 2-page article “OMG and Service-Oriented Architecture”:

In essence, SOA is an architectural approach that seeks to align business processes with service protocols and the underlying software components and legacy applications that implement them.

So far, so good. Then they go on to say:

Both processes and services need to be carefully coordinated to assure an effective SOA implementation. You can’t really do SOA without a clear model of the business process to be supported.

Not sure that I fully agree with that: you have to have a clear model of your business process before you can implement SOA? Aren’t the underlying services supposed to be reusable even if the business process changes? Isn’t that really the whole point of SOA?

And you can’t link your business processes to your service models without the modeling standards the OMG is developing as part of its Model Driven Architecture® (MDA®).

Oh, I get it now.

They do include a nice diagram showing where the OMG standards fit in one representation of an SOA environment (see the newsletter for the full-size version). You can see where BPMN, BPDM and BPEL fit in, which I talked about in my posts from the BPM Think Tank last week, plus other standards such as SBVR (Semantics of Business Vocabulary and Rules) for business rules.

I also like that they’re platform-independent about this, and that they don’t equate SOA with WS-*.

You can check out the newly-formed OMG SIG on SOA if you want to get involved in discussing this MDA approach to SOA.

Stop the SOA 2.0 bull

I’m with the Neils, Brenda, Ronan and David on this one: stop the meaningless “numbering” of an architectural philosophy that is being perpetrated primarily by Oracle and Gartner. Sign the SOA 2.0? No thanks petition:

We’ve created this online petition because we’re dumbfounded at the attempt by certain parts of the IT industry to create and give weight to the term “SOA 2.0”.

Industry does not, at this point, need more confusion around SOA. SOA has real value, but industry at large is only just coming to terms with what it means and what it can do. Inventing terms like “SOA 2.0” might help some analysts and vendors make money, but overall, in the long run it damages us all.

Consider that a big vendor and a big analyst started all this SOA 2.0 nonsense, and you can be pretty sure that their motives are not altruistic. And considering the trademark nonsense that just happened over Web 2.0, lawsuits probably aren’t far behind either.

An online petition on its own may not hold much weight, but if you have a blog, then blog about it; if you’re a customer of Oracle or Gartner, let them know what you think. If the market rejects the concept of SOA 2.0 as so much marketing bull, it won’t fly.

BPM Think Tank Day 2: Greg Meyer keynote

Greg Meyer from iJET gave a “practioner keynote” about process and risk management, and came out with the best quote of the conference so far: “I’d rather have someone tell me how to do something right, than something cool”. Having been at a lot of events recently where people were showing me cool things, but at a lot of customers who want to do things right (and equate “right” with “old and proven”), I find that the real challenge is keeping on the “right” path but remembering that “right” and “cool” are not mutually exclusive: how else do we bring innovation into the mainstream?

Meyer’s talk about risk assessment and human intelligence is fascinating, and anyone who uses the term “combinatorics” casually in his presentation has a place in my engineering heart. 🙂 As a non-American, however, I’m uncomfortably reminded that this is all about making US government intelligence better: iJET started out providing travel information/advisories to travel agencies, then 9/11 happened, the hits on their website increased by 60,000x since they could provide in-depth analysis of the impact of events, and they started providing information to multinational organizations and government agencies.

Putting my uneasiness about their customer base aside, they were dealing with the problem of being a small company that acquired a lot of large customers over a short period of time and had to grow quickly. They implemented an SOA, using an ESB to integrate data and services from many partners and implemented web services to allow partners and customers to access their services quickly and easily. They added a portal architecture to let them create new products and services in weeks or even days, rather than the months that it used to take. However, it didn’t help their bottom line because they had no better insight into how customers were using their products. Basically, they had their head stuck deep in the technology and weren’t considering it from the standpoint of how to improve the real business issues.

Meyer talked about then doing an implementation in the context of the enterprise that actually achieved the success that they were seeking, which appeared to be mostly adding BI (or more accurately, corporate performance management) to feed back metrics to the appropriate parts of the organization, and some better integration with other enterprise applications such as billing systems. The bottom line, not surprisingly, is that you have to consider the entire enterprise for a successful BPM/SOA/ESB implementation.

BPM Think Tank Day 1: BPDM

I’m in Fred Cummins’ BPDM workshop, where his stated goal is to provide a general understanding of BPDM, engage us in a discussion of the requirements, and discuss the implications of BPDM to enterprise agility. Fred’s an EDS fellow who writes occasionally on the EDS Next Big Thing blog.

BPMN and BPDM are both standards that are designed for use by business people, with the inclusion of non-automated as well as automated business processes, and they are both business models as opposed to execution models (like BPEL, WS-CDL or proprietary vendor execution models). BPMN is a standard for the graphical representation of a business process, whereas BPDM is the XML file format in which such a representation can be stored: hence, a tool might display a business process as BPMN and save it as BPDM (which makes BPDM competitive with XPDL from WfMC, which I previously discussed as a file format for BPMN, although Cummins later stated that the scope and goals of BPDM exceed those of XPDL).

We had a lengthy discussion about the relationship between choreography (a collaboration between multiple participants) and a business process/orchestration (how one of the participants manages their view of the interaction): the roles typically map directly between processes and choreography, whereas only the steps in a process that involve interaction with another one of the participants will appear in the choreography. BPDM is intended to capture both orchestration and choreography information, although there was some discussion about whether BPMN has all the graphical representation for everything needed for choreography. It does include the concept of pools (like swimlanes, but representing different organizations, not different functions within an organization) and can collapse a pool so that it is effectively a black box, so I think that it has most or all of what’s required for representing inter-organization choreography. An organization only needs to map the other parties in a choreography as a black box (i.e., a collapsed pool), whereas it will map it’s own internal activities fully within swimlanes in its own pool.

Cummins then moved on to the hot topic of BPM and SOA, with the following definitions/relations:

  • BPM: Business processes are the orderly execution of activities that achieve defined objectives.
  • SOA: Services offer capabilities that can be used in a variety of contexts.
  • Business processes may use services to achieve their objectives.
  • Services implemented with explicit business processes can be more quickly adapted to business changes.

Personally, I find that list a bit circular, and I think that his “definition” of SOA is actually a definition of services — maybe a bit of a fine point. He made a vague point about how processes and services provide different levels of granularity of agility, then came back to make two statements about agility:

  • Primary impact of business changes is on the business processes and organizational structure.
  • The actual work (concrete services) and data of the business tend to stay the same.

I posit that business processes can change in response to changing business because they’ve been implemented using BPM tools that enable this agility, and services tend to stay the same because they haven’t been architected to allow for change. Possibly Cummins’ views are a reflection more of EDS’ client base and their own practices than what’s really possible in terms of agility. Of course, there’s also the view that published services need to stay the same (or at least their external interface) since the publisher may be unaware of all the uses of the service and doesn’t want to risk breaking it, but that doesn’t mean that a service shouldn’t undergo internal optimization or an extension of its functionality as long as it can be easily changed to adapt to changing business requirements.

There’s a lengthy discussion going on now about the difference between defining a meta-process and defining a paradigm, which is getting just a bit too esoteric for my taste (the accusation “you’re being too rigorous!” was just flung around the room), but does remind me that OMG is a standards organization and this is exactly why I prefer implementation to theory, in general… (several minutes elapse)

Cummins finished up with some things that are being considered for BPDM but are still unresolved, such as the integration of business rules (and presumably a BRE) into a business process model, and the integration with strategic planning that’s necessary to make business process modelling a fully participating activity in enterprise architecture.

At the end of it all, this workshop had a lot less to do with BPDM than I wished that it had, and a lot more about some particular views on SOA and business agility that didn’t really have anything to do with BPDM. I understand that BPDM is still a work in progress, but it would have been nice if the artists had unveiled the canvas for us to take a preliminary peek.

Jeanne Baker, who sat in on the session, pointed out that this think tank is for all standards groups, and that last year’s think tank resulted in the merging of BPMI into OMG due to the overlapping scope of BPMN and UML activity diagrams. Maybe the next move is to bring together XPDL and BPDM instead of indulging in an unwanted standards war for business process metamodels.

SOA myths

From Intelligent Enterprise, the top 5 myths of SOA:

  1. If you’re using Web services, you’ve achieved SOA.
  2. You can buy SOA out of the box.
  3. You can simply wrap legacy systems with services.
  4. Once the top executives are sold on SOA, your troubles are over.
  5. SOA is easy.

Check out the article for the details (not particularly meaty) on each.

I consider the last two myths to be self-evident for any type of non-trivial technology, so are a bit frivolous to be included in this list. The first three, however, I run across on a regular basis, and are good to keep in mind when evaluating what you’re doing with SOA, and what vendors are trying to sell to you. My response when I encounter these three myths:

  1. Web services is a set of specific technology standards for building interoperable components. SOA is an architectural and design philosophy that is typically implemented using web services standards, but doesn’t have to be.
  2. You can’t buy philosophy out of the box: “I introspect, therefore I integrate” provides design guidance, but it’s not a ready-to-go product (with apologies to René Descartes).
  3. I’m not so sure that this is a myth, since you could actually wrap legacy systems with services interfaces and they would become valid parts of your SOA environment. The point in the IE article is that maybe this is a good time to reevaluate the systems that you have and replace some of that old legacy stuff, but that’s not an SOA/not-SOA decision per se.

RedMonk Radio podcasts

I’ve been catching up on some podcasts lately — I subscribe to more than 20 via iTunes but only have a chance to listen to a couple of my favourites each day — and finally had a chance to listen to some of the recent RedMonk Radio podcasts from RedMonk, a small analyst firm. I like RedMonk Radio because it’s a conversation between the participants, rather than a formal interview or a standalone speaker, so it’s fun to listen to as well as informative (I especially like James’ imitation of American accents 🙂 ).

In episode 6, James Governor and Michael Coté talk about SOA testing, and the specific problems of testing the heterogeneous SOA environment that most organizations have that includes legacy systems and newer services. There’s a great bit where James states “EAI and SOA are not the same thing, but on the other hand, some of the concepts of EAI, some of the approaches and even some of the technologies are relevant.” Coté asks “What do you think the differences are between the two?” James responds “$40,000 per CPU” (referring to the former market for expensive adapters and connectors that have been replaced by standard web services interfaces), which completely cracked me up. Also some interesting thoughts on testing when some or all of the software/services are outsourced.

In episode 8, Scott Mark interviews James and Coté about life as an industry analyst, which is really about the small-firm analyst experience: I’m sure that things are much different for Gartner analysts, for example. The outside view of analysts is much more glamorous than the reality, but these guys are obviously in it because they have a passion for it, not because they’re making huge buckets of money at it. The funny thing is that the typical day that James described for himself is much like what I do: customer/prospect followups, industry research, reviewing blogs, vendor briefings, writing vendor and technology reviews, and consulting. Maybe I’m an analyst in disguise.

SOA education

I listened in on an ebizQ webinar today, The Path to SOA Enlightenment, and some interesting points came up about SOA education. The sponsor of the webinar was the Integration Consortium, which of course has a vested interest in encouraging SOA education since they already offer training and certification, but there’s few who would disagree that we need better education about a number of integration-related areas. Here’s a few screen snaps of the audience survey responses gathered during the webinar:

The first of these allowed the audience to select more than one response, while the second only allowed the selection of a single reponse. The two above make sense together: if people think that it’s the integration specialists and architects who most need certification, then it follows that the biggest area of training would be concepts rather than technologies.

The next one, which also allowed more than one response to be selected, shows the topics that people feel are important in the training, and there’s a few surprises here, such as organization, policies and governance in first place with 88% of the vote. SOA design and standards almost tied for second with 75% and 73%.

The audience also responded that although only 34% of them have an integration or SOA methdology in place, 87% are interested in having one.