SOA in Action

SOA proponents at a major multi-campus university was able to overcome resistance to their proposed architecture in stages -- one use case at a time. In a recent interview in an e-learning journal, Patrick Masson, CIO at the State University of New York's Delhi College of Technology, recently shared his experiences with establishing an SOA for the SUNY system, which encompasses 64 campuses, 30,000 faculty members, and 414,000 students.

The root of SUNY's SOA effort was a distance learning program, the SUNY Learning Network (SLN), originally begun in 1994 at a branch campus, built on top of a centralized Lotus Notes/Domino system. As the system grew, integration of the distance learning system with other campus systems proved to be a real challenge, particularly with student identity. Each campus had its own student information system (SIS), and students taking both classroom and online courses had to go through a double registration process, resulting in double enrollments.

Another issue was the customization that had been made to the Notes/Domino system, Masson said. "SLN had some 100,000 enrollments managed through Lotus Notes and Domino and had customized the system to such an extent that only a few people knew how it worked. IBM couldn’t support SLN's customizations. This meant that central administration, all of SLN as well as the 40 campuses, was dangerously dependent on a couple of individuals."

The major advantage of the existing centralized system was cross registration across all the campuses, Masson said. "If a student enrolled with SLN they could see the entire SUNY online catalog of courses available from all campuses – not just their own." It was for this reason the university eventually decided to upgrade the system to a service-oriented architecture.

Not without plenty of bumps in the road, however. "The administration didn’t like the SLN 2.0 strategy because it couldn't be easily communicated as an 'out-of-the-box' solution," Masson explained. "It’s a huge undertaking to persuade CIOs and campus presidents to abandon a production and deployment model - the ERP way of doing things. ERP allows people to showcase systems and say: 'wasn’t our money well spent?' An incremental and bottom up approach just doesn’t allow management with those showcasing opportunities."

One way Masson and his team were able to overcome objections or reservations about SOA was through use cases. One of the first use cases Masson employed to sell SOA to the university was dates and calendars, he elaborated. Instead of managing multiple calendars, students will have access information aggregated into a single portal. "The only way is through a SOA," he said.

Through SOA, the STN treats every campus student record system "as a legacy system," and routes student and course data to an abstract data object. "In SLN 2.0 we had decided to start by developing a message broker and a service bus (registry) but we also took on the crusade of developing more standards."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Are we replacing legacy stovepipes with SOA stovepipes?

Mike Reed, managing partner with EWSolutions, warns that many of the 'service-oriented architectures' he's seen more closely resemble the legacy stovepipes they were supposed to replace.

"An old phenomenon is reappearing in a new paradigm – ‘stovepiping’ of applications in a supposed ‘service-oriented architecture,' he explains. "If you or your customer has created an Enterprise Service Bus and/or a service-oriented architecture – but you have not centralized any meta data management or advertised your applications’ ‘services’ – you’ve created another stovepipe! And it is not much different than the stovepiped applications we were creating on the mainframe 20+ years ago."

Service registries and metadata environments separate true SOA from the stovepipes, Reed says. "Customers need to take the hard steps necessary to standardize on things like UDDI (Universal Description, Discovery and Integration). They also need enterprise meta data repositories.... Without these methods to make programs and data available to a broader audience, it’s just the 'same old stovepipe.'"

Unfortunately, Reed adds, "the metadata and services registries are the two hardest nuts to crack, so organizations may be tempted to stop short of this part – I am already seeing this occur at customers. They can reap most of the ESB/SOA functionality 'out of the box,' especially things like message brokering for COTS integration, and Web services, but when it comes time to standardize on directory services or metadata standards, they falter, in effect leaving a 'locally defined' SOA where only services/processes inside the system can interoperate – thus creating a 'Service-Oriented Stovepipe.'"

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Are companies moving toward service-oriented architecture without even realizing it? In a recent interview, Ettienne Reinecke, group CTO at global IT solutions provider Dimension Data, notes that while it may take up to a decade for SOA to become a full reality, many of the pieces are already falling into place -- under many different names and approaches.

Standardization and virtualization, for example, are part of this picture. Most tellingly he added, "I am amazed at the speed with which people are moving away from client/server without even knowing it. They are consolidating data centers, and changing from client/server to XML- and Web-based applications."

Good bye client/server, hello to what, exactly? To bring SOA sensibilities to all these developing pieces of service orientation, Reinecke advises development of a strong architectural program that drives SOA through every project. "Set a basic framework and define standards, then live by them in every project," he advises. "For example, when you do VoIP and you have to deal with IPT numbering plans, use the standard directory service you have defined -- in many cases we see corporations using Active Directory as a standard -- then add your IPT numbers to the directory in Active Directory."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Did you know that projects created primarily from reused software experience only about 1/3 the defect density of those that are new? Or that projects created primarily from reused software take about 1/4 the time and resources of those that are new?

This compelling case for reuse didn't come from the latest white paper trying to make the case for SOA. Rather, it came from a book published by HP back in 1992. Curt Finch, CEO of Journyx, a provider of Web-based software that tracks time and project accounting solutions, cited this early work in a recent post.

To realize the advantages reuse can bring to SOA, Finch advises companies to "start with a very small project and demonstrate success before you implement the big-bang theory." He advises treating SOA projects with rigorous project management methodologies, including the involvement of certified project managers. "Technical and engineering risks will be high if your organization hasn't done this before," he says. "The testing and verification portion of the project gets more difficult, as does the communications management."

Finch, who has extensive programming experience, sees reuse as the most compelling advantage of SOA going forward. Are we finally reaching this holy grail?

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Sandy Carter, vice president of IBM in charge of everything SOA, recently provided a series of tips for approaching the CEO about an SOA project. Here are a few key pointers:

Don't call it 'SOA': "Explain the value and benefits in business terms that reflect the organization's goals -- such as cost reduction, productivity, competitive advantage, etc. -- before diving into a technical conversation."

Vision, not version: "Outline the immediate and long-term results from this strategy while avoiding discussions about specific version numbers." Also, Carter advises, avoid technical jargon all together.

Build consensus throughout the company: "Prove the value of SOA through small test projects conducted with volunteer departments in the organization."

Start small yet live large: "When selecting those small test projects, choose to integrate and automate those business processes that can have the most widespread, positive impact across the organization."

Show conviction and prediction: "Articulate goals for each step along the SOA path. By publicly stating and achieving realistic goals for the organization based on an SOA -- increasing productivity or decreasing
costs by XX percent -- you can bolster confidence in the project and overall strategy." Be sure to set goals and track performance along the way.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Let's face it: the business doesn't have a clue about SOA. Surveys tell us that all the time. But SOA is supposed to be led by the business. Is there anyone out there in the enterprise who can break this impasse?

Miko Matsumura, vice president of webMethods, recently said in an interview that such a person does exist in many enterprises. If they don't exist, they can be cultivated -- enter the "visionary architect."

However, the VAs are going to need some help, as they can't turn around the enterprise by themselves, Miko continues. "Once you get into serious deployment of SOA, part of the scalability of the system requires a scalability of understanding," he says. "Part of what we're seeing is visionary architects that are bringing SOA to their organizations are hitting some boundaries and barriers when it comes to the rest of the organization in terms of really getting it."

The paradox of SOA is that the companies that could really benefit from the enhanced agility and flexibility that SOA provides are the least likely to implement SOA. Why? Because the progressive, forward-thinking organizations that are taking the lead with SOA already have corporate cultures that are open to innovation. Those creaky, hidebound organizations with a lot of well-fortified fiefdoms and a CYA management philosophy simply aren't going to be open-minded enough to want to go the SOA route. If you're an SOA proponent in one of these organizations -- and there are many of you -- you are likely spinning your wheels on Web services projects that are promising but remain confined to a silo. Such organizations need an SOA evangelist who can connect with the C-level suite and sell the SOA concept.

Miko says the visionary architect can fill this role, and proposes helping these individuals from without, "There's a need for this enlightened architect figure to team up with a bigger partner to actually help scale up the education piece," he states. The challenge is "these individuals will be in short supply."

We need enlightened architects to promote SOA, but they will be in short supply.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Dave Linthicum picked up on my JBOWS (Just a Bunch of Web Services) discussions and, in a recent podcast, connected the dots between JBOWS and SOA.

Dave observed that many organizations he's visited thought they had an SOA, but were, in reality, still in the JBOWS stage, in which they are simply Web service-enabling back-end systems. There's nothing wrong with JBOWS, as it's a first step toward SOA, Dave says. "Whether you want to call that an SOA or not, that's up to you," he said. But, "in my mind, you're not really getting to the value of SOA."

Unlike Web service-enabling systems, SOA "is a systemic change in the way your do enterprise architecture -- not something you can do in a couple of months project," Dave says. "It's going to take a long-term commitment to changing the way you're doing enterprise architecture, so that it aligns with something that's more agile."

In all likelihood, a JBOWS architecture is not orchestrated, does not have a registry, has no process-based testing, does not reuse the services, and has no management tools. Web services often are deployed and managed on a piecemeal basis by enlightened individuals or departments that are attempting to do end-runs around calcified management structures. But this is where many organizations stand.

Dave poses some questions to determine whether you are building a JBOWS, or a true SOA:

- Are the services a true representation of the core behaviors found in your key enterprise systems, as well as new services required to provide other critical behaviors?

- Have those services been abstracted for most foreseeable uses?

- Are the services combinable into composites, and are those composites well defined?

- Is there a plan for governance and security, managing the use the services?

- Are both the information and services abstract-able to an orchestration/process layer for configuration-oriented agility of most of the IT assets?

- Is your information/data managed in such a way that you're loosely coupled from the underlying physical schemas?

Dave raises some good points about the role of of SOA in data management, enabling sites to "take big messy databases and make them look less messy." In most data centers, "the physical back-end databases are messy, and, ultimately, not combined around logical entities such as sales, orders, transactions, and employees. We do this as a mechanism for loosely coupling the local representation of the data from the underlying physical representation. It actually enhances agility."

If you are still stuck in the JBOWS stage, don't despair, Dave adds. "Not to worry, JBOWS can be a good start towards a SOA. Just know, you're not there yet."

Posted by joemckendrick in  |  Permalink  | Comments (0)  | TrackBacks (0)

How far along are we in the SOA-BPM dance? In a new blog post, Mike Stevens cuts right to the chase, and does a good job of summing up the opportunities and challenges arising at the intersection of these two mighty forces.

The opportunity: "BPM’s promises – like cost and time savings as high as 70 percent – are hard for companies to ignore," Mike writes. BPM and SOA have similar philosophies -- "both are based on the idea of creating processes out of building blocks that can be easily linked together and easily modified down the road (because you can modify the process one block at a time)."

The challenge: BPM is from Venus, SOA is from Mars. Or, more precisely, BPM advocates tend to be business managers, while SOA advocates tend to be IT managers. There's a historical mistrust between the two groups. Plus, there is often resistance to change wrought by BPM efforts.

Posted by joemckendrick in SOA  |  Permalink  | Comments (1)  | TrackBacks (0)

As compliance became an necessary part of documenting IT operations, it created a flurry of new paperwork requirements. Lately, some companies have begun building SOA and Web services solutions to remove the new paperwork burden being placed upon them.

For many companies, manual efforts to extract data for compliance required generating reports for a particular quarter, then repeating the same steps again three months later.

"When an auditor would come in, and look at one of these processes, we would hand them a three-inch binder of paper, and they would look through it for exceptions to quiz you on," according to Mike Rulf, vice president of advanced engineering for USinternetworking, an on-demand hosting provider and AT&T subsidiary. "Auditors aren’t cheap, they charge pretty good bucks, and it takes a lot of time to go through that stack of paper."

The problem is pervasive. In a survey of 211 data center managers that I helped conduct and wrote for the Oracle Applications Users Group last year, we found nearly four out of 10 respondents from the largest enterprises say they are having difficulty extracting and combining data from multiple brands of enterprise applications, such as Oracle ERP/CRM/Financials, PeopleSoft, Hyperion, SAP, Siebel, and custom-developed. (A copy of the study is posted here).

There has got to be a better way. And SOA approaches offer a new way to streamline and automate compliance processes, and make them repeatable.

I recently had the opportunity to chat with Rulf, who provides services to large companies with multiple compliance reporting requirements. USinternetworking's pain point was its efforts to automate or manage business processes around systems audits, Rulf said. Many of USinternetworking's clients are large companies that require reporting on the ERP and financial systems that they outsourced. "Our processes tended to span a lot of several commercial packages -- we run PeopleSoft for financials and CRM, and Ariba for procurement. We also have a lot of internal systems that we use for monitoring, management, and event reporting."

USinternetworking deployed SOA with several components of Oracle Fusion Middleware to capture and leverage the information coming out of these systems into standardized cross-system services, Rulf explained.

As part of the modeling process for USinternetworking's SOA, Rulf and his team went around and "talk to all these people that in the past we were shepparding binders of information to." Often, these individuals would take the paperwork dropped on their desks, and re-key the information into another script they were running for reporting purposes, which resulted in more paperwork being generated. "We found with SOA, we could take all these little chucks of code, and build these standardized wrappers that can be presented as Web services."

Rulf added that compliance mandates are a good way to get support from management for SOA initiatives. "The primary driver behind our SOA is the process automation. It gave us economies of scale. If we’ve got something that we do 20 times a day, or even just 20 times a week, by having a standardized way of doing it, where you manage just to the exceptions, there’s significant cost savings just with having that available to you."

Ultimately, Rulf said, "when you talk to a C-level executive, or somebody in management, they want to know how quickly they can get to the point where they sign a customer to get to the first invoice. They don’t care that I sent 15 things through PeopleSoft, and sent 50 orders in Ariba. They care about, 'how fast did I get these people through?' 'Where did I have errors?' 'Where else can I streamline that process flow?'"

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

In a new piece in ComputerWorld, Dave Linthicum predicts that 2007 is set to witness a significant surge in SOA spending, However, he questions whether it will be money well spent.

"2007 will witness a significant surge in SOA spending, as early adopters evolve POC (proof of concept) implementations into more robust deployments and late adopters buy into the architectural shift. Lack of insight and foresight, however, will spur many enterprises to divert too many dollars to areas that will prove less fruitful in ensuring the long-term success of their SOA."

Where will the money go? First of all, Dave points out, companies will be diverting too much money to follow the hype, Dave points out -- and corporate resources will be consumed in "excesses for steering committees, conferences, and POCs to the detriment of real work getting done."

In addition, a lot of funds will flow toward governance solutions and ESBs, but in many cases, too early in the process, Dave continues. "Many enterprises will look to vendors for an 'SOA in a box' before they understand their own requirements. In other words, they'll buy the house before they know where they're going to put it."

Then, there's that $5.5 billion that will be spent on SOA consultants (according to IDC estimates).

Dave also offers some excellent recommendations as to where all those funds should go. First, he states that companies shift more funds to training -- to bring up IT staffers' skills in managing organizational as well as technical issues. Plus, not enough funding is going to security, which "will again be an afterthought in 2007... Scrimping on funding now will not make up for potential losses down the road.... Exposing services gives SOA power -- not only to reap savings but also to do a lot of damage."

Finally, not enough resources will go into new paradigms such as SaaS (software as a service) and Web services marketplaces -- which could generate the highest ROI, Dave says.

SOA isn't about the bits and bytes that will go into new equipment or consulting engagements -- its about organizational transformation. Unfortunately, as Dave points out, many companies will still fall into the old trap of funneling money to slideware and appeals to fear, uncertainty and doubt.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Vendor acquisitions and governance were big on the SOA radar screen in 2006, and portend more of the same for 2007. Is what's happening in the SOA space indicative of our willingness and readiness to go all out with enterprise SOA, or simply vendors trying to cash in on fear, uncertainty, and doubt?

I recently had the opportunity to help debate this question in a panel discussion podcast, led by Dana Gardner, to talk about the year just passed and the year ahead in SOA. (Link to podcast here.)

Dana, a principal with InterArbor Solutions and ZDNet blogger, asked panelists (teve Garone, Jon Collins, Tony Baer, and myself) what we thought the most important development in 2006 was, and what 2007 will bring for SOA.

Jon Collins of Macehiter Ward-Hutton made the point that 2006 as the year that "SOA has become mainstream," at least for IT companies. The evidence was in the wave of acquisitions of SOA vendors, he said. However, ironically, "the one thing that’s been lacking so far is integration, which is to me the ultimate irony, because its exactly what SOA is about as a concept. It’s about helping bring together the disparate pieces."

Dana questioned the prominent play governance has been receiving, given the early stages of most SOA deployments. "It seemed that the value here was that, you're going to be headed toward some sort of a train wreck if you ramp up SOA, so we have to put governance into play. Yet, these things remain predominantly as pilots, isolated -- not horizontal, not yet at the scale where the system is breaking down under load, pressure and volume. Yet, there is this big drive to governance. Governance is a way of extending SOA into a larger role of transformation, taking over where policy and even directory left off -- it' sort of a land grab by these vendors into this larger domain of how to actually manage your business, not just your IT."

Steve Garone of AlignIT Group agreed, and added that this positioning is creating a great deal of confusion in the market. "There's been a lot of talk about enablers to SOA -- governance, ESBs, which I think is another very important one. Because of the way vendors approach providing solutions, sometimes the enablers become a point of confusion to the point where it actually slows down adoption. I think some confusion around standards is also playing a role in that."

I agreed as well, but also interjected that it was interesting to see Microsoft begin talking up SOA in recent months: "To Microsoft the ESB probably meant enterprise service buses or those vehicles that employees ride around on at the Redmond campus. It seems that Microsoft has gotten on board with the ESB concept lately as well, which surprised a lot of observers, because Microsoft usually likes to take its own route with things and not buy into the acronym of the moment."

What about the year ahead? Aside from vendor FUD, what will 2007 bring? Dana predicted that 2007 will be "the year of modeling," which will bring more robust tools and approaches to choreographing services.

Steve Garone predicted that divisions within organizations will continue to hamper enterprise-wide SOA efforts. "A lot of folks on both sides of that pointing fingers and claiming that the other one doesn’t get it." As a result Garone continued, many SOA efforts remain ground in pilot implementations.

Tony Baer of OnStrategies said that for the most part, rather than attempts at "big-bang" SOA implementations, the vast majority of implementations will take a safer, more "boring" route — incrementally. "I think the mainstream will incrementally get to the first things beyond the skunkworks stage."

I opined that perhaps the term "SOA" (but not the concept) will begin to have run its course, and vendors may begin playing up some new themes, perhaps Event Driven Architecture. I also agreed that SOA efforts may get more C-level cred in 2007, but another problem may rear its head — simply having enough staff to get SOA efforts going. IT budgets are going strong and there's shortages of the right types of skills popping up all over the place. For enterprises that need to keep their day-to-day operations going, it maybe difficult to allocate the human resources to really move SOA projects forward.

Posted by joemckendrick in SOA  |  Permalink  | Comments (2)  | TrackBacks (0)

Ben Bernanke, chairman of the Federal Reserve Board, famously said that "the best way to get out of trouble is not to get into it in the first place," and those charged with SOA projects would do well to heed his advice and create a foundation for SOA governance, management and quality as early as possible.

Ian Bruce, of Systinet/Mercury/HP, says the free market of economics and the emerging free market of business services have a lot in common. In both cases, free markets unleash the power of innovation and drive progress, but need some measure of oversight to keep things from getting out of hand.

As Ian puts it, in many ways IT executives responsible for SOA face the same problems as Bernanke, who "needs to support a free market that makes maximum use of economic resources with minimum governance, interventions and safeguards." Likewise, Ian points out, "IT leaders implementing SOA need to support a free market of business services that makes maximum use of IT resources with minimum governance, interventions and safeguards. The goal is to govern enough to ensure maximum business benefits, while mitigating risks."

This is where SOA governance comes in. I have had the opportunity to work with Ian on projects in the past, and consider him a "go-to" guy when it comes to questions about governance. Ian has just put together a checklist for ebizQ, which should include the following elements:

SOA visibility and information management: "Visibility ensures that services can be easily found and understood by service consumers, and that consumers have access to a 360° view of a service at every phase of its lifecycle. SOA needs a single system-of-record for services and all the related metadata surrounding services."

SOA policy management: "The nature of SOA (highly distributed, heterogeneous and very dynamic) means that it is critical for SOA artifacts to be governed by specific business, technical and regulatory policies. A policy might specify that orders from a premium customer will be routed to a high-performance server, or that financial transactions require data encryption and authentication. An SOA policy defines configurable rules and conditions that affect services during both design time and run time."

SOA contracts: "A service contract should provide a precise and unambiguous definition of how the provider and consumer interact. Contracts are typically created at the point of service consumption. But this is not to say that they must be rewritten each and every time. Many contracts can and should be retained and reused to form the basis for many provider/consumer agreements and, thus, contracts represent another important SOA artifact that should be managed for reuse."

SOA lifecycle management: "The only way to achieve the full promise of SOA is by managing services and other SOA information across this complete lifecycle."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Saugatuck Research has just released the results of a study which looked at the state of service-oriented architecture progress at this time, as well as make predictions about what's going to happen over the next five years.

Overall, the study's authors, Michael West, Bruce Guptill, and Mark Koenig -- all analysts at Saugatuck -- provide a fairly realistic assessment about what's going on with SOA, circa 2007. Namely, that SOA is plodding along much more slowly than one might think, given the hype that has been surrounding the architecture over the past year or so.

While the study is only based on interviews with 40 IT executives and application architects, Saugatuck explains that these were "deep-dive" interviews which really took a hard look at what these companies were actually doing, and how they were doing it.

Thus, perhaps the most revealing revelation of the study is that while many of the executives (15, or 37% of the bunch) initially described their projects as "service-oriented architectures," further probing revealed that these were actually collections of Web services, or early SOA pilots at best. As the Saugatuck analysts put it, "it became clear that many are merely managing a collection of Web services, and have yet to make a strong commitment to SOA as a management discipline — as opposed to an integration technology."

Another revelation to come out of the study is that most of these SOA projects are driven by technical or IT-centric purposes, rather than business purposes. The study finds that by a wide margin, cost reduction outdistances all other motivations to move to SOA by a two-to-one margin. In the study, 57 percent cite cost reduction, 27 percent cite code reuse (which is cost reduction), and only 23 percent expect to increase business agility from their SOA any time soon.

Interestingly, ebizQ's survey on SOA practices, conducted in September, found the opposite trend: business goals -- versus IT efficiency -- are driving most SOA deployments at this time. Almost two out of respondents, 64 percent, said that the goal of their SOA effort is to "increase business agility," followed by "IT reuse" at 57 percent. "Business process optimization" followed with 55 percent, and another 44 percent sought the advantages of composite application development.

However, both the Saugatuck and ebizQ surveys agree that most companies are still in the very early stages of SOA implementations. What will the next five years bring in SOA, then? The Saugatuck analysts advise us to be patient, as SOA will only grow through slow, steady progress.

The study's authors say that we are still wrapping up the "First Wave" of SOA (1999-2005), which consists of experimentation, pilots, and services confined to departments. We are currently in the midst of an overlapping "Second Wave" (2003-2009), in which SOAs are rolled out to serve departmental purposes. The coming "Third Wave" of SOA will be more an enterprise stage, in which services are shared across business units, and alas, business agility begins to be achieved. This stage will be realized by most companies by 2012.

The primary driver of SOA at this time -- cost reduction -- will not begin to kick in until Wave III, and that's likely top be overshadowed at that point by emerging business benefits such as agility. In fact, Saugatuck notes, don't expect any cost containment anytime soon with an SOA deployment: "Users must be prepared for their initial SOA projects to be as much as 100 percent more expensive – and to take longer – than traditional software development approaches."

That's where effective governance will make the difference. "The earlier you start Governance efforts, establish Centers of Excellence and launch an awareness program, the more likely you are to achieve the objectives of agility and business process flexibility when entering the third Wave of program-based enterprise-wide initiatives," the authors note.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

My ebizQ colleague Elizabeth Book just made it official: ebizQ will be launching a new virtual conference in March, called "BPM in Action." The conference will be in the same spirit of the recent SOA in Action conference, launched in November.

Michael Dortch, a noted author, speaker on BPM topics, and analyst with the Robert Frances Group (RFG), will be the "designated blogger" for the BPM in Action site. As the designated blogger for SOA in Action, I would like to welcome Michael to this new launch, and urge readers to keep checking out the BPM in Action site. SOA needs BPM, and BPM needs SOA.

Posted by joemckendrick in  |  Permalink  | Comments (2)  | TrackBacks (0)

You read that right. If you really want to determine the worth of a service-oriented architecture to your business, try setting it up without any particular technology in mind. JP Morgenthal, principal with Avorcor, posits this line of thinking in a post -- to make the point that SOA is not about IT.

All too often, SOA is tangled up with technology, servers, and infrastructure. However, technology actually inhibits service-oriented thinking. Perhaps its time to to think of SOA purely in business process terms. "Let me put this to rest right now, SOA has nothing (N-O-T-H-I-N-G) to do with IT. It is a design pattern that can be applied to any type of system in the world," Morgenthal says.

To illustrate his point with even more clarity, Morgenthal points to McDonald's -- which has perfected a human-based SOA. That's right, there's no law that says SOA can't be human based.

Just look at McDonald's with drive-up windows, which presents all sorts of communications problems, with all the surrounding noise. "The solution is pure SOA and the only technology involved is purely telecommunications," Morgenthal says. To improve quality of order fulfillment at the drive-thru window, McDonalds plans to connect its drive-through window ordering system with a call center. "Wow! Do you get it? McDonalds does! They turned order taking into a service. A service that, if they choose to in the future, they can outsource with no impact to the processes that are in place."

Morgenthal adds that "this is what SOA is about. It doesn't belong to IT. If you're responsible for designing processes that are optimal, redundant, foolproof and reliable, then YOU ARE RESPONSIBLE FOR SOA! To be ultra clear here -- if you design your system as a set of services, such that the service provider can be changed without impact to your processes, then you might be an SOA."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Is SOA "Same Old Architecture"? It shouldn't be.

Building service-oriented architecture calls for fresh thinking on many levels, often at odds with tried-and-true, familiar IT approaches. Namely, that the successes of SOA often will not immediately be seen and felt by the business; and that applications should not be built for the ages. The goal of SOA is to increase flexibility, through the decoupling of both systems and processes.

Two recent articles cast some light on this new thinking. In a report in Computing Canada, Bruce Johnson, a partner and consultant at Toronto-based ObjectSharp.com, observes that "If done properly, an end user should never know whether SOA is being used or not." The challenge is that for the most part, "SOA may very well be invisible to most of its stakeholders."

Thus, management buy-in becomes a challenge, since SOA isn't tangible, and its results aren't necessarily tangible. "They are likely to say, 'Why did you spend six months on this and not change anything?'" Johnson warns.

Loose coupling is the key, Johnson is quoted as saying. "SOA is more of a philosophy than a technology. It requires a shift in mindset because developers no longer need to know what specific objects will be used for - instead, they need to develop things with a final outcome in mind."

Loose coupling is the goal, and many of today's systems are coupled too tightly, according to a new article in Linux Sys-Con. SOA should reduce such coupling on two levels: Technological coupling, which deals with transport protocols, data encoding schemes, authentication mechanisms, and is often the result of decisions made by system architects; and functional coupling, which deals with interaction and exchanged data, often the result of decisions made by analysts and domain experts.

The problem with tightly coupling systems is that it assumes that applications are systems created to last forever. They shouldn't be, and SOA is all about agility to change on a moment's notice. "The technology is always improved, new data is collected, organizations are restructured, merges occur, and new laws and regulations are passed," the article notes. "High coupling is a trait that complicates systems maintenance and makes it more expensive to manage. Highly coupled solutions are more difficult to modify since changes made in one place cause changes to be made somewhere else."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)