SOA in Action

Jim Webber, a thought leader from ThoughtWorks, also known as the "World Wide Webber," has been out preaching his message on "guerrilla SOA." He recently appeared on this podcast on the InfoQ site. Jim not only states a good case for his ingredients for guerrilla SOA -- MEST (great explanation here) and SSDL (SOAP Service Description Language) -- but also reminds us of the whole purpose of SOA in the first place. Here are some snippets from his recent interview. I know Jim from my WebServices.Org days, and Jim hates middleware with a passion, as you will pick up from this interview.

Q: What is 'guerrilla SOA'?

Jim Webber: "A lot of SOA projects that I’ve seen have been somewhat akin to mobilizing an army… you have hundreds of consultants.. ..a whole bunch of armaments in the form of huge sophisticated middleware platforms… and …the whole thing is very heavyweight and somewhat cumbersome..

"When you’re going for that kind of big upfront SOA.. …you lose a lot of opportunity to prioritize and deliver your business options based on your business priorities and business values."

Guerrilla SOA turns that around. You’re looking for a much more lightweight engagements. We want to address discrete business problems, organize priorities according to the business stakeholder, and get those processes implemented rapidly in an incremental way with lots of feedback."

"So we can actually start to prioritize across the business which processes are the most value, and which ones are most heavily used and so forth. And implement without having to wait for a big program of work to be established. Put the ESB in place, or other kinds of technical dependencies."

Q: Does this work in both large or small scenarios?

Jim Webber: "The nice thing is it works in either. Because you have specific priorities the business gives you… any given time, and focus on those. As long as the business can keep coming to you, you can scale ad infinitum, up until the point you've implemented all the processes in a given domain or in a given business."

Q: Is this approach compatible with large-scale vendors' middleware?

Jim Webber: "The approach helps us to decouple dependencies between what the businesspeople want and the tools we have available, ESBs and so on. I would absolutely use those tools to where it make sense to me.. to implement the process that I’ve been instructed to automate. If it doesn’t make sense, I wouldn’t use them. I would use other tools -- simple job apps, store and forward-based architectures, message brokers -- where it makes sense within my current context."

"But the important thing is I don’t let my current development context bleed -- I don’t let those abstractions leak into other development projects. We like to keep each process that we’re implementing relatively isolated, so that the service ecosystem grows. On the other hand, if we allow everything bleed together into a big SOA platform, you tend to get tight coupling and so on. And that restricts your options for evolution further down the line. The business people can see we have this much broader view of the processes as a whole."

Q: What's the risk with tight coupling?

Jim Webber: "The classic scenario is that if I’ve got two systems that are tightly bound, and I change one, I risk breaking the other. We saw this back in the day with CORBA processes, tightly coupled through an IDL, now we have Web services, where we tightly couple through another IDL called WSDL. With tightly coupled systems, there's a ripple effect. When I come to you and say I’m going to make changes, first reaction is no, because you’re going to break me. Then we get into this paralysis, where neither of us can make progress, because we’re so scared of damaging each other. We need strong governance and so on and someone to strongarm to make both parties move."

Q: What's the alternative?

"Instead of sharing types, I think we should start to share business schemas and business messages -- owned not by the technical people, but by the businesspeople. That gives me as the developer of a service an interface that I would make sure that I adhere to… and honor the contract in my service implementation."

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

The US Government, which knows a thing or two about security, has just issued a guide to Web services security, entitled NIST Special Publication 800-95, “Guide to Secure Web Services.” (The full PDF of the guide is available for download from the National Institute for Standards and Technology here.)

The guide, written with the help of consultants from Booz Allen Hamilton, points to the following issues plague Web services security:

o Confidentiality and integrity of data that is transmitted via Web services protocols in service-to-service transactions, including data that traverses intermediary services

o Functional integrity of the Web services that requires the establishment of trust between services on a transaction-by-transaction basis

o Availability in the face of denial of service attacks that exploit vulnerabilities unique to Web service technologies, especially targeting core services, such as discovery service, on which other services rely.

o SOAs are dynamic and can seldom be fully constrained to the physical boundaries of a single network.

o SOAP is transmitted over HyperText Transfer Protocol (HTTP), which is allowed to flow without restriction through most firewalls.

o Transport Layer Security (TLS), which is used to authenticate and encrypt Web-based messages, is inadequate for protecting SOAP messages because it is designed to operate between two endpoints. TLS cannot accommodate Web services' inherent ability to forward messages to multiple other Web services simultaneously.

The NIST guide makes the following recommendations for ensuring the security of Web services transactions:

Replicate Data and Services to Improve Availability. Since Web services are susceptible to DoS attacks, it is important to replicate data and applications in a robust manner. Replication and redundancy can ensure access to critical data in the event of a fault. It will also enable the system to react in a coordinated way to deal with disruptions.

Use Logging of Transactions to Improve Non-repudiation and Accountability. Non-repudiation and accountability require logging mechanisms involved in the entire Web service transaction. As of early 2007, there are few implemented logging standards that can be used across an entire SOA. In particular, the level of logging provided by various UDDI registries, identity providers, and individual Web services varies greatly. Where the provided information is not sufficient to maintain accountability and non-repudiation, it may be necessary to introduce additional software or services into the SOA to support these security requirements.

Use Threat Modeling and Secure Software Design Techniques to Protect from Attacks. The objective of secure software design techniques is to ensure that the design and implementation of Web services software does not contain defects that can be exploited. Threat modeling can find security strengths and weaknesses, discover vulnerabilities and provide feedback into the security life cycle of the application. Software security testing should include security-oriented code reviews and penetration testing.

Use Performance Analysis and Simulation Techniques for End to End Quality of Service and Quality of Protection. Queuing networks and simulation techniques have long played critical roles in designing, developing and managing complex information systems. Similar techniques can be used for quality assured and highly available Web services. Enterprise systems with several business partners must complete business processes in a timely manner to meet real time market conditions. The dynamic and compositional nature of Web services makes end-to-end QoS management a major challenge for service-oriented distributed systems.

Digitally Sign UDDI Entries to Verify the Author of Registered Entries. UDDI registries openly provide details about the purpose of a Web service as well as how to access it. Should an attacker compromise a UDDI entry, it would be possible for requesters to bind to a malicious provider. Therefore, it is important to digitally sign UDDI entries so as to verify the publisher of these entries.

Enhance Existing Security Mechanisms and Infrastructure. Web services rely on many existing Internet protocols and often coexist with other network applications on an organization’s network. As such, many Web service security standards, tools, and techniques require that traditional security mechanisms, such as firewalls, intrusion detection systems (IDS), and secured operating systems, are in effect before implementation or deployment of Web services applications.

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

The insurance industry, which probably has more legacy mainframes per square inch than anywhere else, has a reputation as a conservative industry. However, a new report out of Insurance Networking News finds insurance companies may be on the verge of an SOA revolution.

In a Q&A with Mark Gorman, analyst with Tower Group, Gorman observes that "iInsurance carriers are increasingly looking to the promise of BI to help them make more precise, more accurate, more consistent and more timely decisions across a wide array of business processes. To do so they are enhancing their capabilities at capturing, analyzing and utilizing data."

SOA enables BI services to be made "potentially available to any person, process or transaction regardless of the timing, location or type of transaction being executed," Gorman said.

Gorman's associate, David West, elaborated on this convergence taking place between BI and SOA: "In addition to improvements in consistency, accuracy and timeliness of decisions, a key value proposition of SOA for BI is its financial return," he said. "Service-oriented BI systems carry a lower total cost of ownership. This architecture enables organizations to optimize their use of hardware so that components of BI systems run on the platform that makes the most sense from a cost/performance perspective."

Areas where BI services are being employed include marketing applications, such as lead generation or lead assignment, product selection for cross-sell or up-sell opportunities, or channel selection for new product offers, Gorman says. Other areas include automated risk assessment and pricing precision capabilities during new business, and renewal application processing.

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

My colleague Beth Gold-Bernstein recently recounted a Software-as-a-Service experience with an all-too familiar ring. That is, when an error occurred in the application, she made numerous attempts to first fine, then contact customer support. She eventually inadvertently found herself on the line to the owner's mother. (Then again, it was the "parent" company Beth was trying to reach...)

I too, use SaaS-based vendors to do survey research work. One vendor I was using earlier in the year had an application that worked okay, but the vendor had a nasty habit of taking the system down for upgrades or maintenance without first telling customers.

Last February, I had prepared a survey for launch on a Monday morning, timed with a large email blast. I happened to be on the road in California, and three hours after the 9 am Eastern Time launch, I found out -- through worried emails from the survey's paying sponsor -- that the survey form wasn't coming up in the browser. Working the crisis from a hotel room, I found out that the survey vendor had taken the system down over the weekend, and ran into complications trying to install the new system.

That time they answered their phone, but a little while later to my chagrin, they were taken over by another company, and the support representatives I was used to calling vanished.

Yes, there is a risky side to SaaS. Beth points to the spotty service that one SaaS vendor provides. Another issue is data -- who stores, manages, and has control over your data?

A few months back, I spoke to Dave Mitchell, director of software-as-a-service strategy for IBM, who noted that “most of the start-up application vendors are selecting SaaS [Software as a Service] as their primary model, and increasingly as their sole model for delivering applica­tions.” If you're going with a SaaS-based startup, what guarantees do you have that they'll be around and up and running six months from now?

Dilip Wagle, a partner with McKinsey & Company, told me that one of the biggest risks is that end-user compa­nies may have less control over the reli­ability about how their data is managed. ‘Pure ‘in-the-cloud’ services imply that all the customers data are essentially stored off-premise in a data center owned or contracted by the service provider,’ he explained. ‘In the event of data center failure on the part of the service vendor, the customer has no recourse but to hope that data were appropriately backed up and managed in a secure fashion. The problem can be exacerbat­ed if the SaaS vendor in turn, out­sources back-end data center operations to yet another third party. This can com­plicate accountability and liability in the event of failure or security breach­es,’ Wagle said.

SaaS is quickly displacing the install-from-the-CD-and-cross-your-fingers approach to software — good riddance to that. But SaaS also makes us even more reliant on third-party firms which may be here today and gone tomorrow. Especially if we’re going to those startups Dave Mitchell was talking about. Remember that creed that IT managers have been living by for decades now — whether its applications, data, or coffemakers — always, always, have a backup.

Posted by joemckendrick in Software as a Service  |  Permalink  | Comments (1)  | TrackBacks (0)

Lorraine Lawson recently posted an insightful commentary about the SOA-Software as a Service connection, drawing on observations by Robert Schneider.

Schneider pointed out that many SaaS vendors “get it” when it comes to SOA: "their offerings are much more SOA-friendly, and often comply with many of its best practice guidelines. Of course, there are some horrendous exceptions to the rule, but SOAP-based, WSDL-defined services have become the de-facto standard for integration with SaaS solutions."

By employing SOA in their solutions, SaaS vendors smooth the way for integration among their customers.

And the synergy works the other way as well. Namely, that SOA can be viewed as SaaS, delivered internally. SOA essentially is "Software as a Service" contained within the enterprise walls.

The analogy makes a great elevator speech, especially if one is hard-pressed to describe the philosophy of SOA to end-user customers, whose eyes tend to glaze over when they start hearing about WSDL and BPEL and loose coupling. But SaaS -- everyone gets that. You don't have to buy and install the program CDs, you just use what you need off the Internet, and are charged on a metered basis.

Does SOA not work in the same fashion when delivered across the enterprise and beyond?

Rather than building, maintaining, or delivering their own services, business units subscribe to SOA-based services from a publisher somewhere else in the enterprise, or even outside the enterprise. Someone else worries about upgrades, maintenance and testing; you consume the service, and pay on some pay-as-you use arrangement. Sounds a lot like Software as a Service.

Conversely, while SaaS providers themselves may not necessarily be using SOA, it's probably in their best interest to align their services using SOA methodologies and protocols.

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

When a railroad company set out to build an SOA that could handle 5.8 millions messages a day for 1,500 trading partners, as well as track more than seven million pieces of equipment, the emphasis was on business-IT coordination and cooperation more than anything else.

Rich Seeley, writing in SearchWebServices, describes how Railinc, a wholly owned subsidiary of the American Association of Railroads, pursued an SOA strategy by first establishing an SOA center of excellence to help forge communication and interaction between the business and IT.

Operating a railroad is a complex undertaking. Rail cars and shipments need to be shifted and moved to the most optimal locations to ensure quick delivery from coast to coast. That's why one rail system chose to move to SOA, to ensure that the right information is sent out to its 1,500 customers. Railroad companies, vendors and shippers rely on the information that Railinc's IT systems provide, which includes repositories of equipment information, location information, and movement information. This includes data on the status of railroad cars and shipments that are used by both the railroads and shippers.

As Garry Grandlienard, Railinc's IT director of enterprise architecture and center of excellence lead put it: "When a train's approaching a location like Chicago, that train is going to be broken up and cars are going to be moved around to other railroads. So if they don't have good accurate information, that will really slow down the speed at which the freight moves through the system."

The SOA center of excellence was first established to coordinate the company's move from its existing legacy EDI system to an SOA-based system. Information can now be accessed anywhere via a PC with a Web browser.

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

At least one big vendor says that the best route to business process management is through SOA. Or, conversely, the path to SOA goes through BPM.

IBM, it is reported, is throwing a ton of resources at bringing together business process management (BPM) and service-oriented architecture (SOA), and, hopefully, in the process, getting IT to think more like business users in order to use this technology more effectively. (PDF available to registered ebizQ members here.)

That's the latest word from Dennis Callaghan, analyst with the 451 Group (and a colleague of mine going back to our Midrange Systems days).

IBM, in its IBM Way of doing things, has launched a head-spinning assortment of initiatives around fusing BPM and SOA, including products, partnership programs, and university-based certification programs.

But in the big picture of things, Dennis observes that "such a confluence of technologies means that IT will have to collaborate more with business users – and so will need greater knowledge of the business side."

There are other vendors tacking in this direction as well, including SAP, Ramco Systems, BEA, and Sun Microsystems, Dennis observes.

Posted by joemckendrick in Business Process Management  |  Permalink  | Comments (1)  | TrackBacks (0)

Two newly published studies show that some progress is being made on the road to SOA -- but the journey has only begun. That is, if Just a Bunch of Web Services is in New York, and SOA in Los Angeles, most companies are still somewhere in New Jersey. (That's okay -- New Jersey has some great beaches.)

Aberdeen Group recently surveyed about 400 companies and found that there is a split in the market, between those simply deploying Web services applications (which they call “SOA Lite”) and companies building out a full SOA middleware infrastructure. (A link to the report’s PDF file is here.) The survey is underwritten, in part, by BEA and Hitachi Consulting.

Overall, Aberdeen defined about 20% of the survey group as “best-in-class” enterprises. Another 50% were “average,” and at least 30% could be considered “laggards.”

The best in class companies have taken the lead with full SOA deployments — 56% report SOA-enabled middleware deployments, versus 45% with mainly Web services deployments (doesn’t equal 100% due to rounding). In contrast, only 11% of the laggard companies reported full SOA deployments, versus 43% mainly involved with Web services. (What are the remaining 46% doing? Who knows...)

SOA efforts have paid off well for these best in class companies, Aberdeen found. All of the BICs, 100%, say they saw reductions in their application development costs. By contrast, only 59% of the average companies could say this, along with 14% of the laggards. Likewise, while 89% of the BICs said customer satisfaction levels went up, this dropped to 69% among the average companies. Among our friends, the laggards, however, only 14% could claim increases in users satisfaction levels.

In addition, the BICs have adopted the SOA ethic in many other ways. At least 29%, for example, have deployed SOA governance software, compared to 17% of the average companies and 6% of the laggards. In addition, 61% of the BICs have retrained their application development teams in the SOA way — compared to 24% of the average companies and 29% of the laggards.

Surprisingly, there is one area the laggards are keeping up with the BICs, however — 33% within each group are employing new processes to test and assure the QA of their SOA applications.

In addition, another survey published by Evans Data also concludes that progress is being made, but most companies are still somewhere on the New Jersey Turnpike. At least three-quarters of companies that have built or are building Web services now planning to implement SOA. At present, more than one in five have already built some kind of formal SOA for company-wide adoption.

However, the survey of 400 companies, for which I authored the final analysis report, confirms that most organizations are still somewhere in the transitional stage between JBOWS stage (Just a Bunch of Web Services) and SOA. In fact, most have not gotten their arms around the various pieces needed to make up SOA: governance and registries, ESBs business process management, and service sharing/reuse.

The Evans Data survey shows there is some progress in this direction – a significant segment of companies now are building services that can be reused and redeployed. In fact, more than 70% have experienced a cost saving as a result of code reuse and automation of processes. However, the survey also shows that few companies are ready in terms of governance and management of cross-enterprise services. Testing and validating Web services is the greatest challenge for developing an SOA, along with determining an ROI.

The Evans Data survey also found that SOA is no longer just a luxury available to high-end companies – it’s reaching commodity status as technology available to the mass market of companies, including small to medium-size organizations. For the first time in this survey series (conducted since 2003), open-source tools surpassed commercial products in Web services and middleware development.

The survey also finds increasing reliance on frameworks to move SOA forward. The survey finds that number of companies planning or executing SOA deployments on a Java Platform increased slightly during the last six months while those planning to build SOA implementations on .NET decreased by almost 20%. .NET deployments for SOA are still ahead, with 31% targeting that platform, but with 28% now expecting to target Java technologies; the rival platforms are virtually tied. Almost one in five companies are expecting to support both.

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

Things are gearing up for the SOA in Action virtual conference scheduled for October 30 and 31st -- just a couple of months away, believe it or not!

The folks at ebizQ have assembled an incredible schedule of top-flight speakers and compelling topics:

Gartner's Roy Schulte -- who shaped much of today's SOA thinking -- will kick off the event with a discussion of the progress (or lack thereof) with SOA and Web services standards; the rise of Event Driven Architecture, and the latest developments around Business Activity Monitoring.

Then, Brenda Michelson and ebizQ's own Beth Gold-Bernstein -- two of the top thinkers in SOA today -- collaborate on a joint presentation on business driven design, which is a method for creating right-sized business services that can be traced back to business requirements. This is sorely needed in today's enterprises, many of which are struggling to strengthen the link between technology and business value using SOA.

Following Brenda and Beth, yours truly will moderate a panel discussion on the convergence (or lack thereof) between SOA and Web 2.0 approaches. I hope to help explore how to connect the dots between Web 2.0 and SOA.

To wrap up this first day, Dennis Byron, our resident open source guru, will lead a session that connects the dots between open source software and SOA. The session will present new ebizQ research into the various ways that open source software (OSS) enables SOA.

Forrester's Randy Heffner keynotes Day Two of the conference, with a discussion of the major categories of SOA infrastructure products, as well as providing guidance on how to construct a workable plan for evolving into a strategic SOA platform.

Dave Linthicum -- a very informative speaker and writer who practices what he preaches -- follows up with an overview of SOA security strategies -- something we need more of.

To wrap it all up, Beth will moderate a panel that will look at the converging trends of BI, BPM, and EDA as they tie into SOA.

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

While it's going to take some time for most businesses to gain value from SOA, there's no question that SOA consulting itself has become a booming business.

In a new post here at ebizQ, Dave Linthicum (an SOA consultant himself) probed the dark art of SOA consulting, and why consultants' promises need to be carefully scrutinized.

SOA is new to everybody, so don't be sold on gobs of "SOA experience." Dave astutely observes that many past projects that consultants tout may actually have been JBOWS (just a bunch of Web services), "and have no underlying mechanisms to provide agility, which is the core benefit of SOA.... The problem is that many of people looking to hire SOA consultants don't understand the difference between JBOWS and a true SOA, and accept JBOWS as 'experience.'"

Dave advises hiring "consultants who understand that SOA is really about configuration, agility, and changeability, and not just about service enablement. It's very easy to expose services; turning those services into solutions is another level of sophistication."

Many consultants are a bit too chummy with vendors. As a result, Dave points out, they'll implement the same vendors and technology each and every time.

Many consultants oversimplify the process, or even skip planning altogether. With SOA, there needs to be a predefined process, Dave points out. It's better to sweat it out at the beginning and get SOA right the first time. However, too many consultants have a different agenda -- "Their main focus is the selection of the technology, or, in some cases, they attempt to force fit a problem with a predetermined technology solution. This can never be good."

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

Having just spent time in Toronto, I was interested to see this new story on the Ontario provincial government's implementation of service-oriented architecture.

Interestingly still, Ontario has been at it for close to a decade, calling it their "common components" approach. "For us, SOA is more a re-branding of an approach we've had in play since about 1999," Ron Huxter, the province's chief technology officer, is quoted as saying.

Ontario's SOA didn't start out as a huge, concerted drive to service-orientation. Rather, there were many developments along the way involving different departments and applications. "It was more the realization of a thousand points of light than a single thunderbolt," Huxter said.

Things started in 1998,when the government consolidated 24 ministry IT departments, creating eight new IT organizations responsible for "clusters" of ministries with similar or related responsibilities and ways of doing business. According to the article, the new IT organizations were charged with "harvesting as much reuse as possible." In addition, 24 different HR and ERP systems were replaced by single enterprise-wide systems.

The province's SOA effort includes SOA centers of excellence that develop and implement shared tools and platforms based on .NET framework and Java Platform. A Common Components & Applications branch helps identify common components and applications.

The SOA effort met plenty of resistance at first. Developers and managers within the ministries resisted the idea of sharing and reusing each other's services and applications. As Huxter put it, "to provide service in a common way threatens your ability to control how you provide service. You're putting your eggs in someone else's basket."

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

When thinking of SOA governance, I like the analogy of a condo or neighborhood association. That is, there is no single owner -- everyone is the owner. Yet, there has to be some overseer in place to provide support and set policies to keep the neighborhood from disintegrating into a weed-choked, trash-strewn wasteland. Or, even worse, a bunch of houses with drapes that don't match.

But what exactly is governance? Many in the industry talk about registry, change management, and policy management. But there's a lot more to the story than that. It's a people thing. As with the neighborhood association, power has to be delegated to a management committee to fulfill the wishes and needs of the community. People need to feel assured that things are getting done. They need a place to work out their grievances. This all applies to the enterprise as well.

So, yes, governance boards are needed. Some of the essential elements of good governance are explored by Ooi Sze Kai in a new report in CIO Today:

Planning: What's the business problem that needs to be addressed? "SOA project leaders should focus on understanding the overall scope of the governance need within the organization and identify areas for improvement. Most of these activities are people-centric and focus on extensive collaboration between IT and business management."

Defining: Business and IT professionals need to agree on new approaches to creating policies at this stage. This includes "policies for service reuse across lines of business, putting funding mechanisms in place to encourage reuse, and establishing mechanisms to guarantee service levels."

Measuring: "All governance arrangements need to be monitored, managed and measured. this provides the opportunity to evaluate the results." This includes evaluating arrangements such as service-level agreements, reuse levels and change policies.

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

This October, ebizQ will be putting on the second annual edition of its SOA in Action virtual conference. THis year's SOA in Action will include Webinars with live Q&As;, interactive booths where you can chat with vendors and other visitors, podcasts and a partner resource center.

Last year's conference includes a roster of top SOA analysts and strategists. This year will include more top-notch talent to discuss the latest trends and things you need to know about SOA. And, oh, by the way, I'll have the honor of joining this esteemed group to moderate a panel on SOA-Web 2.0 fusion.

While ebizQ is still in the process of finalizing the agenda for the upcoming conference, preliminary topics under review include Event-Driven Architecture (EDA), SOA & Enterprise Architecture: Intersection of SOA & EDA, BPM, and BI, Open Source SOA, and SOA and Web 2.0: Mashups, SaaS, and Collaboration: Putting the Pieces Together.

This year's conference will also feature a contest for best SOA implementation -- SOA Idol. Submit your SOA solutions and innovations, and watch the votes role in as our members rate your solution. You will also be entered into a chance to win either an Apple iPhone and a chance for an all-expense paid trip to the SOA in Action Virtual conference! (As far as I know, however, Simon Cowell will not be judging.)

The conference will be held October 30 and 31.

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

One of the most oft-stated goals of SOA is achieving the long-sought "business-IT" alignment that has eluded organizations for generations. Supposedly, under an SOA regime, businesspeople and IT folks would communicate often and work in harmony toward common shared goals.

But does does this Utopian vision translate into real dollars and cents for the business, or is it more of a feel-good thing promulgated by consultants? Well. a new study seems to say, yes, business-IT alignment will equate to business success. (Consultants, breath a sigh of relief...)

The BTM Institute looked at the state of companies across 50 industries in 2002 and again in 2006, and actually connects the dots between success and “converged technology management.” The study, called the “Business-Technology Convergence Index,” finds that in various metrics, well-aligned (or better yet, "whole-brained" enterprises) fared far better in their markets then their mal-aligned counterparts. (PDF of the study available here.)

The numbers are impressive. The report states that companies with well-aligned IT-business operations saw 12% average annual growth versus four percent for their industry groups. In addition, the aligned IT-business companies saw 36% average annual earnings per share growth versus seven percent for their industry groups.

So how did BTM determine which companies are “whole-brained” versus not-so-whole brained? BTM said that it looked at factors such as process maturity, process automation, and governance. Across the more high-level organizations studied, you can see the natural relationship between well-managed and repeatable processes and SOA, which encourages such best practices:

Governance: “…there is a consistent, managed process for ensuring that business management is fully engaged in decision surrounding business technology… …there is clear communication of business technology initiatives…”

Strategic technology investments: “…there is a standardized means of structuring projects and of ensuring that they are managed in accordance with enterprise standards…”

Enterprise architecture: “…there are documented, integrated business and technology architectures which describe the organization fully and which represent the business technology necessary for it to reach its goals.”

Enterprise data model: “For these organizations, data has become information. …this information is available through and managed in an integrated, enterprise-wide automated system that facilitates decision making…”

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

"The key to successfully doing something is in successfully understanding what you're doing."

With these words of wisdom, Thomas Erl, noted author and analyst on all things SOA, kicks off his latest book, SOA: Principles of Service Design, which covers many of the fundamentals of SOA. Erl's goal in publishing the work is to help developers, architects, and IT managers evolve into "true" SOA professionals that can deliver service-orientation to the enterprise.

The book is packed with information and insights, and here are just a few observations Thomas makes about moving to service orientation:

There's nothing "new" about SOA: Interestingly, Thomas points out that "service orientation has deep roots in several past computing platforms and design approaches, and is therefore not considered a revolutionary design paradigm."

SOA benefits are many: Thomas points out that the "key benefits of service-oriented computing are associated with the standardization, consistency, reliability, and scalability established within services." He adds that SOA "provides the potential to elevate the responsiveness and cost-effectiveness of IT."

Reuse is important, but not the whole story: While reuse of services is seen as the best route to economies of scale, Thomas points out fast and efficient integration is a benefit that can stand on its own. In fact, in many surveys I have seen and conducted in recent years, integration continues to be the main driving factor to SOA. Thomas affirms that "if reusability were to be omitted as a design characteristic, significant interoperability-related benefit would still be attainable."

SOA is ultimately about the enterprise: Thomas points out that as SOA gains more traction within an organization, the reach of IT architecture begins to expand beyond traditional boundaries as well. "The enterprise perspective becomes increasingly prominent," he points out.

SOA is mainly about Web services: While many observers argue that SOA is about all types of services, Thomas argues that Web services is clearly the driver of SOA, and vice-versa. Web services is "primarily responsible for the popularity of SOA," he says. "Conversely, the rise of service-oriented computing has repositioned and formalized the Web services technology set from its original incarnation." Thomas also states that "Web services currently provide the foremost means of implementing services."

Silos weren't all that bad, but SOA is better: The traditional silo-based approach to building applications, Thomas observes, "has been successful at providing tangible benefits and measurable returns on investment." However, he adds, silo-based computing increased complexity and administrative burdens on IT." SOA eventually reduces this complexity and burden, he adds.

SOA may be more expensive and complex -- at first. While SOA can reap significant long-term benefits, Thomas also cautions that it's not easy getting it all started. SOA introduces "design complexity and the need for a consistent level of standardization," noting that the "construction of services can be expensive and time-consuming, introducing a more burdensome project delivery lifecycle, further compounded by some of the common top-down analysis requirements that need to be in place." SOA also has the effect of shaking up the IT organization, he adds.

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