Enterprise architecture

OMG call for input on UML roadmap

More than a few people feel UML took a turn with its 2.0 version that helped improve the lot of embedded systems vendors and their customers, but did not improve the lot of rank and file developers. All that was some time ago. Now UML steward OMG is calling for comment on future directions for UML. The OMG is inviting individuals to respond to a Request for Information ahead of a workshop dedicated to issues of future development of UML. What do you think? How should UML evolve.

Trends in BPM and modeling

Technologies rarely evolve neatly in straight lines. Instead they bump into one another, and influence each others’ directions. Think of a rack of billiard balls when the cue ball strikes! As an example, look at the technologies that converged in IBM’s recent BPM BlueWorks, which is a modeling tool set for business processes available as a service via the cloud. To top it off, BlueWorks is built in part on IBM’s sMash Enterpirse Mash-up development tool technology. In fact, the front end of BPM, the area where the processes are modeled is very active just about now, and IBM is far from alone in innovating. Continued »

Watching the Feds pick a CTO and CIO

Over the years, the Federal government has had considerable influence in seeking to define the role of Enterprise Architect. As a new administration gets rolling in Washington, there is some chance that its approach to hiring a new chief federal CIO and CTO will affect future trends in EA. The CIO and CTO positions have been filled with Vivek Kundra and Aneesh Chopra, respectively. Seers of the tea leaves of technology have pondered those choices, and hit the blogs running. Continued »

Bruce Silver on BPMN

We have heard the story of aligning IT and development before, haven’t we? That the story is told over and over does not make it a bad story per se. Some stories bear retelling. If the details change over time, that is helpful.

I mention this while perusing one of the more useful BPM-related blogs. That is Bruce Silver’s BPMS Watch. There have been significant changes in BPM in recent years, and a new notations for workflow description are among them. Silver’s site, and his accompanying columns for the BPMInstitute.org cover this and other ground quite well.

Recently Silver wrote about BPMN as ‘the first serious attempt to provide a common visual language for process description shared by business and IT.’ Well, I don’t know. Journalists very seldom call something the ‘first’ of anything. It is a sure way to get mail from an irate someone who built something before someone else. But irate mail’s a good thing, especially on the blogosphere, so I will let this stand, although I’d have to add that I did hear UML described this way more than once upon a time.

Related BPMN info
Bruce Silver blog - www.brsilver.com
Bruce Silver on BPMN - www.brsilver.com

Policy and contract focused architecture

Perhaps architects are paying too much attention to the services when they work on service-oriented architecture implementation, writes Neil Ward-Dutton. He suggests that they might focus on “contract-and-policy-oriented architecture (CPOA).”

Continued »

Application modernization: COBOL meets .NET

How will IT organizations maintain the COBOL applications written by the whiz kid programmers of the 1970s? Continued »

Test SOA for the unexpected

Testing service-oriented architecture requires thinking outside the box to the point that your test cases hit an application with totally unexpected input, argues Thomas Fredell, CTO of IntraLinks. Continued »

Monson-Haefel talks of Curl as Ajax frameworks grow

Some of the challenge to architects these days comes not from the server side where so much integration effort has been placed, but from the client side. There, Ajax has arisen to improve users’ interactions with multiple application services.

But, as Richard Monson-Haefel told SearchSOA.com’s Rich Seeley, the unending proliferation of thinly supported open-source Ajax frameworks may cause architects for proprietary RIA-alternatives to Ajax. The long-time Burton Group analyst recently took a spot in the Curl brain trust.

Rich writes of his conversaion with Monson-Haefel in How to sort out Ajax and RIA frameworks. Monson-Haefel cites Curl, Flash and Silverlight among RIA choices some individuals are now considering. What do you think?

So how SOA are ESBs?

Last week we at SearchSOA.com ran a story about how ESBs aren’t as interoperable as users might expect them to be. The story prompted a response from StrikeIron CEO Dave Linthicum, basically wondering if the bigger problem here is bad architecture. He wrote:

Call me crazy, but would it not make more sense to have a centralized plan as to what the SOA should be, based on the requirements of the business, versus people dashing out and shelling out the dollars for an ESB for some one-off tactical reason, or more likely just acting out of reaction to the hype? Now, you’re left with a dysfunctional mess that’s not easily corrected, and clearly costly.

Joe McKendrick over at ZDNet picked up on that and put together a brief history of ESB criticism. Linthicum’s blog entry also drew a lot fire down in its comments section (be sure to check them out as iTKO’s John Michelsen, the interviewee in our original article, makes a few points on the unavoidable nature of multiple ESBs). The response in fact spurred Linthicum to write a follow up entry addressing some of the critics of his first entry. After pointing out many of the dysfunctional things he’s heard over the years, he wrote:

[W]hat I’m asserting is that there has to be some architecture forethought behind dragging any technology into the enterprise, and I suspect that’s not occurring.

To be fair, he doesn’t suspect it. He knows that’s the case. We all know that’s the case. As Software AG’s Miko Matsumura put it in another article we ran last week, “People are addicted to messed up IT.”

Anyway, Linthicum finished his latest post with a request:

So, in the spirit of having an open mind, send me your reasons for leveraging multiple ESBs, and why that’s a good approach for your enterprise architecture. Also, while you’re at it, make sure to send me the reasons you’re using an ESB to begin with: your requirements and the reasoning behind the solution. I won’t post them unless you say it’s okay.

It’s an interesting topic, so make sure to send Dave your reasons, if you’ve got some. For my part, I know a lot of people who despise ESBs. During one interview I did with an analyst back in 2005, he referred to ESBs at “methadone.” This was actually praise for the ESB, making the case that it was better than EAI. Yet I know others who just as adamantly argue that at some point you’ve got to implement a service or pull together applications after a corporate merger, and at that point you will find yourself wanting an ESB.

Earlier this year, I actually did a podcast with Mulesource CEO Dave Rosenberg about why he maintains that enterprises will need to accommodate multiple ESBs inside their SOAs.

I would argue the larger point here, and this is where Michelsen was focused in the original article, is that multiple ESBs are a fact of life. No matter if it may be sub-optimal in terms of architecture, a good architecture should be able to tackle this kind of problem, or at least good governance should help ameliorate it. Mergers and acquisitions will happen. You will need to combine services with outside entities. Different divisions will buy disparate products, even if they shouldn’t. This doesn’t even touch on technology creep from the open source arena.

So it’s really two questions. The first is do you even need one ESB let alone many? It’s a fair question and one that every end user ought to put serious thought into answering. The second is, how do you deal with multiple ESBs in your infrastructure? Because no matter how you answer the first question, you will need to manage this situation for at least the near term.

Having trouble with SOA? Pay attention to the architecture

There are some anecdotal claims out there in cyberspace that some companies are struggling with SOA. Mind you, we never really hear who these companies are or much about the details of what kind of trouble they’ve had.

That makes it hard to assess what the problem is. Are these users actually pursuing service orientation or are they buying products with an SOA label and expecting them to work miracles? I suspect the latter is a common trait of those who feel they haven’t gotten enough bang for their SOA buck.

Here’s one thing I can tell you: I’ve lost count of how many slide show presentations I’ve seen on SOA, but in every success story presentation I’ve ever seen there is an architecture slide. For instance, when I saw a presentation in April by State Street Corp. centered around how it’s using an ESB for the messaging involving the $15 trillion in assets in has under custody, the slide show did not proclaim ESBs are great and everyone should have one. Instead it delineated where the ESB fit inside State Street’s architecture, what role it served and how it played with other critical functionality in achieving the scalability, reliability and high performance that State Street desires.

If you can’t produce a representation of your architecture and then demonstrate that you’ve actually built systems in accordance with that architecture, then you can’t claim to be doing SOA. You may have undertaken a Web services project or bought some product that might be able to help you with an SOA if you had one, but there is no getting around the primacy an architectural blueprint. Those who lack it are begging for trouble.

Interestingly, in our user survey last fall, readers reported that the top SOA development challenge they are facing is a lack of internal skills or training (30.5%). Nothing else even came close. It’s no secret that the supply of architects who actually understand SOA is lagging behind the demand. Yet the discipline involved with service orientation is far from obscure.

Recently we ran two articles from Thomas Erl about the difference between service orientation and object orientation (second part here). We also recently published some architect best practices. And if you need an example of what can be achieved by adopting a service orientation perspective and paying attention to your architecture, look no farther than this case study from ING Card. ING adopted exactly no new technology when it first waded into the SOA waters and was able to streamline its international credit card business. They were able to do this because they had an architecture at the core of the business plan.

Analysts often wear themselves out reminding users that SOA isn’t something you buy, it’s something you do. Well, architecture is the something you do.