SOA in Action

In a new Q&A published at SearchSOA, Dana Gardner surfaces a part of IT always pushed to the background in every sweeping paradigm change. Yet, no paradigm change could happen without it.

We're talking about storage, that is. The question is: Doesn't SOA ramp up demand for persistent storage? Actually, Dana pointed out, a well-implemented SOA increases efficiencies and improves the way the moving parts of the enterprise interact with each other. Dana makes the point that storage itself has been "service enabled" long before people thought of service enabling apps.

Indeed, the notion of storage area networks (SANs), in which storage devices are pooled and seen as one single storage device across all parts of the enterprise definitely seems to be a precursor to SOA. This may have been the first cross-enterprise technology-sharing venture, and perhaps there's a few things we can learn from the experience. For example, how does a business unit that has invested heavily in massive storage arrays share these devices with other users? Are there any chargebacks in place? How are storage budgets distributed across users?

Ultimately, the storage behind SOA will benefit from greater efficiencies, made possible by extending the service-oriented mentality to both applications and data. As Dana put it: "The biggest payback over time will be the effective use that SOAs make of these newly modernized data services. In effect, SOA makes all the major parts of IT infrastructure and assets work better together, and so the investments in storage efficiency and data rationalization and transformation may be the best examples of how the reduced IT TCO whole is greater than the savings already gleaned from the storage parts."

_____________________________________________________________________

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

Forrester analyst Randy Heffner, who has made frequent appearances here for ebizQ events, has just released a report that describes the best way to "build a SOA." (Full report available here at ebizQ.)

Or actually, as Heffner points out, the multiple ways to build a SOA. "There is no one best sequence for building an SOA platform," he writes. "Even though most SOA platforms start with messaging technologies such as HTTP, SOAP, REST, and message queuing, there is no one dominant way or sequence in which to build an SOA platform. The wide diversity among various organizations’ existing software infrastructures, combined with each firm’s different priorities and drivers for SOA, lead to a wide diversity of investment streams for building SOA platforms."

Plus, Heffner adds, incrementally is the best way to go. Businesses keep changing, as do SOA products, so "the majority of firms evolve toward their SOA platform."

According to Heffner, Forrester recommends the following five steps for building an SOA platform:

1) Identify existing infrastructure’s SOA capabilities. In other words, know what you already have, Heffner says. This helps avoid duplication, especially when it comes to spending money on new products. "Identify which functions your existing products provide fully or partially."

2) Identify priorities for new SOA capabilities. Pull out or develop application roadmaps and estimate how SOA-based services will map against these plans, Heffner says. "identify the major types of service implementation styles that will be required for the high-priority services you must build over the near term. For example, service orchestration or legacy integration might be a high priority for your SOA platform, in which case, the first step is determining whether your existing infrastructure can fulfill these requirements. If there are gaps, you can then investigate SOA specialty product categories, such as ESBs or integration-centric business process management suites, to learn how they might close the gaps."

3) Identify your long-term needs for SOA capabilities. This determines what kinds of products a company buys down the road, Heffner says. "Identify your high-level long-term needs for your SOA platform. For example, you may be able to get by for now with lightweight SOA management capabilities (e.g., simple monitoring of service implementations) based on your existing IT management tools, but you will likely see a future need for the stronger SOA features and functions that an SOA management solution provides (e.g., managing service contracts for SOA-based services)."

4) Match your platform plans to your organization’s investment strategy. "Most organizations buy products in connection with specific projects," says Heffner. "However, we see an increasing number of firms that intentionally position such purchases as merely the first stage of a growing investment in the selected products, with each subsequent solution project expanding the investment to meet its needs."

5. Evolve your SOA platform in line with the business value of solution delivery projects. "Find the investment that, within the current project’s bounds of affordability, meets near-term SOA requirements fully," Heffner advised. This is "the approach that best keeps an SOA evolution on track and that has the most palatable investment model."

____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

In today's news, ebizQ reports on a new bulletin issued by Butler Group which made the case that any and all SOA depends on governance. However, as Butler Group states, governance is more than putting a bunch of technologies in place, be they registries or repositories. The real issue is on an organizational level -- often, services are put into production long before governance comes along, and then everything has to be retrofitted.

As we have found in surveys conducted here at ebizQ, most early SOA efforts do not have governance of any kind in place -- typically, organizations hold off until they have some type of critical mass of services before they consider it worth investing in governance. As Butler's Rob Hailstone put it: "Most organizations deploying SOA leave it too late to implement effective governance. The longer you leave it, the more difficult it becomes to 'retrofit' governance to an operational SOA environment. However, the effort must be made if the SOA initiative is not to descend into chaos."

The recent ebizQ survey, conducted in partnership with SAP, finds that even companies with the most advanced SOA deployments – in terms of enterprise reach and number of reusable services – have yet to formulate governance strategies or methods to measure the value of their SOA to the business. The survey finds that only one out of seven companies currently have active governance efforts underway.

The low level of governance is perhaps not that surprising, since many organizations are just starting their SOA implementations. What was eye-opening about the survey, however, was that even among the most advanced sites surveyed, two out of three companies do not yet have comprehensive governance programs in place. In addition, many respondents see their current or planned governance programs as being ineffective, the survey finds. Even among the most advanced SOA efforts, governance is not delivering its full value.

I recently joined SAP's Christian Hastedt Marckwardt in a Webcast discussing the survey results, and the evolving role of SOA governance. (Click here to access the full Webcast.)

_____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

What are people working on these days, SOA-wise? That's the question put forth by SOA entrepreneur extraordinaire Dave Linthicum, who reports that the pace of SOA is slow, but steady.

Companies are not jumping head-first into new approaches and technologies, but are carefully planning and considering where they are going. Every SOA is coalescing into a different and unique combination of patterns (like snowflakes, DNA, and landfills). And while that doesn't mean a rush to embrace SOA, that's a very good thing.

Dave says he's seeing five essential activities underway at many locations:

Modeling and implementation: "Holistic modeling of the SOA and all of its working parts."

Security design and implementation: "Figuring out how you're going to secure and govern your SOA."

Semantic understanding and metadata modeling: "Identifying all application semantics and defining the common metadata model."

Service design and implementation: "Designing services properly, implementing them, and tracking them."

Orchestration and process modeling: "Modeling processes, and implementing them directly from the model."

Note the strong emphasis on modeling. This is important in making the architecture clear and tangible to the business users. Dave adds that SOA practitioners "are not yet looking for 'key enabling SOA technology,' at least not yet." As shown by the above five areas of concentration, the focus is on setting up methodologies, defining deliverables, determining how all of these artifacts are related, and education.

____________________________________________________________________

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

In many posts on this blogsite and across the ebizQ universe, we talk about how bad duplication of systems, services, data, and staff time can be. Bad, bad, bad -- down with duplication.

However, some duplication of systems and efforts may be okay for some businesses. What's important is that the business itself decided that the duplication is okay and fits a business purpose, and the decision wasn't solely left to IT.

I just published a piece in the June issue of Insurance Networking News on IT governance, a concern that is shaping the way IT interacts with the business, and visa-versa.

Jeff Goldberg, analyst with Celent, said governance is essential because "no longer can IT make decisions inside of a black box... In many cases, IT has unilaterally made major systems decisions without thinking about the business implications, such as the purchase of a content management system. As a result of lack of governance, "multiple IT projects end up competing with each other for scarce IT resources."

I also had the opportunity to speak with Brian Abeyta, VP of the IT project management office at AFLAC -- you know, the insurance company with the goose. He described how IT governance has been baked into the company's culture -- from the president on down to line managers. AFLAC's IT governance is led by a high-level steering committee chaired by the US president. At the next level is a "C-level" review board, then, for smaller projects, boards run by line-of-business VPs. Until this board structure was put in place two years ago, Abeyta said, IT staff resources were often consumed with projects that extended beyond their useful life.

Since this article was in Insurance Networking News, it discussed the requirements for organizations with multiple, diverse lines of business, which is the trademark of this industry. The result is separate systems in a lot of different silos, run by managers who don't regularly interact with each other. So that means plenty of duplication. For example, you may find two separately maintained $10-million policy administration systems within the same unit of the same insurance carrier.

Sounds wasteful, and hopefully doesn't drive up rates. But then again, there may be a business reason for keeping this duplication. Many companies may want to keep this duplication because certain aspects of each system provide competitive advantage, or leverage with a vendor that supplies other requirements. What governance enables managers to do is to speak up about these decisions, Goldberg pointed out. "While the business may ultimately decide it is in its best interest to maintain duplicate systems, the important thing is that the business -- and not just IT -- made the final decision."

___________________________________________________________________

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

Fellow ebizQ community activist Brenda Michelson provides a glimpse of panels the SOA Consortium will be hosting at the impending Gartner AADI and EA (Application Architecture, Development, and Integration and Enterprise Architecture) Summits, to be held in O-Town, FLA.

Todd Biske will be involved with both panels, so you know it will be good -- extremely reasoned and informative.

On Wednesday, June 11 at AADI, Todd, along with Melvin Greer and Mike Tavis, will be talking about measuring the value of SOA. The panel, to be moderated by Gartner's Daniel Sholler and SOA Consortium's Richard Soley, will explore companies' experiences in justifying and measuring the value of their SOA activities, including developing initial business cases and continuously demonstrating the benefits.

On Friday, 13 June at EA, John Williams, Maja Tibbling and Marty Colburn will join Todd to discuss SOA & EA lessons learned from the trenches. This panel will be moderated by Gartner's Bruce Robertson and Richard Soley. Panelists will look at the links, synergies and dependencies between SOA and EA. They will address the big question of the moment: How does SOA fit into the EA picture?

_____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Events • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

For some time now, I've heard consultants and analysts propose launching "centers of excellence" or "competency centers" to better manage newer IT initiatives such as SOA is one that has been proposed by consultants for some time now. Not only does such a body help kick-start SOA efforts in the business, but it's also a way to keep such efforts above organizational politics and fiefdoms. The SOA effort can proceed without being encumbered by individual department or management agendas.

Excellent idea. However, such efforts have been slow to evolve, and may be difficult for smaller to medium-size businesses to get in place. ebizQ's recent survey on SOA governance, conducted in partnership with SAP, found that only nine percent of respondents had established some form of competency center/center of excellence to promote and keep SOA efforts on the right track. Almost all of these were larger companies with revenues exceeding $1 billion or more annually. (Our Webinar on the survey results can be viewed here.)

While getting management to commit time and resources to an SOA center in and of itself may be an uphill battle, there may be value in extending the reach of such centers to enterprise data integration as well, according to John Schmidt, VP of Informatica and Chair of the Integration Consortium. This center may be described as an "Integration Competency Center," or ICC. In a chat with Beth Gold-Bernstein, Schmidt provides some guidelines to help businesses of all sizes implement an Integration Competency Center (ICC). He describes the elements that go into an ICC:

Financial management: "The ICC operates as a shared service. This is a set of best practices around charge back for shared infrastructure and individual services."

Architecture: "The ICC does not do enterprise architecture, but is responsible for the information architecture. They work with the enterprise architecture group, and 'connects the dots,' by mapping schemas to physical data sources to enable the translation, transformation, and integration. This ICC is the central federated repository."

Business Process Management. "This is not BPM per se, but this includes service flow modeling, information flows, business event modeling, and common definition of business events."

Integration methodology: "The process of running an ICC, defining it, organizing it, all the things you need to run an integration group, and how it will interact with other IT groups."

Metadata management: "The ICC group is responsible for data assets. Metadata ends up being a federated model."

Modeling management: "This includes techniques around canonical data modeling, what are the best practices, how do you build them."

Integration Systems. "This is about running integration systems as a specific class of applications – all the discipline of how your manage, plan and operate the system."

_____________________________________________________________________

Posted by joemckendrick in Data Management • Management • SOA • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

Financial services companies have had a tough ride over the past year, so anything that can be done to better take advantage of their information technology assets to streamline operations and increase the situational awareness and agility of the business is a good thing. That's where SOA and business process management (BPM) come in.

JPMorgan Chase, of course, is right at the epicenter of the financial storm that has been ravaging the industry, and the company's dominance and stability is due in no small part to its ability to smartly leverage SOA and BPM.

At ebizQ's recent Financial Services Live Panel, Ron Ambuter, CTO of the BPM Workstream Group at JPMorgan Chase, described how his company has been able to adapt and adopt technology and methodologies to help reduce costs, improve customer experiences, and maintain a competitive edge. Ronan Bradley, analyst with Lustratus Research and former CEO of PolarLake, led the discussion, and was joined by Keith Swenson, chief architect at Fujitsu Computer Systems, and Hub Vandervoort, CTO of Progress Software. (Archived recordings and transcript available here.)

Ambuter described how JPMorgan Chase was interested in the concept of reusability, which would help the organization "get better leverage out of the efforts that we were making to build and buy applications by reusing components instead of rebuilding and rebuying them over and over again."

With the troubles the industry has been having around subprime mortgages, writedowns, and tighter credit, it's likely

regulation and oversight will only increase, particularly in regards to risk management. Bradley questioned whether the prevalence of regulation holds back or encourages SOA adoption. Ambuter said regulatory mandates have accelerated his company's drive to SOA, noting that "the concept of SOA allows us to react probably quicker, and more expeditiously, more cost effectively."

The panel also discussed the challenges around extending managing services and infrastructure across multiple groups within organizations. Financial services organizations, of course, typically have multiple lines of business, from securities to brokerages to mortgages. Ambuster explained that organizational issues were his greatest challenge as well in implementing a cohesive SOA and BPM strategy at JPMorgan Chase. "We have rules and responsibilities that are compartmentalized by groups of folks, and we realize that as you go into this stuff, education and cross-pollination of information is critically important. It's not just the technology folks that need to understand this stuff, it's the risk folks, and it's the governance folks and it's the finance folks, and it's the business side folks."

Vandervoort agreed that "it's easy to get bogged down in trying to get alignment on a lot of different points across all the groups." He recommended three approaches to the problem, including "getting your transports aligned between business entities so that you can use eventing-oriented mechanisms to communicate across domains"; establishing SLA and security policies that ensure visibility; and establishing a common enterprise data model.

"You have to get your semantics aligned among the members," he said. "And that doesn't have to be a common vocabulary in its entirety, but certainly what we regard as the data in flight, those things that fly between domains and different working groups have to be highly normative."

Aligning SOA and BPM is also important. "While SOA is basically a technology trend, BPM is essentially a management trend," said Swenson. "A lot of people look at BPM and they get confused between the management trend and the technology trend. A lot of technology product companies have looked at BPM and looked only at the technology and come up with a kind of a programming language that they claim to solve the problem, which is great for the IT side of the house, but it leaves the business side out of this. As far as the adoption of BPM goes, one of the biggest barriers to adoption of the real business process is essentially the fear that the manager will lose control of the process."

Complex event processing is also a key initiative financial services companies need to undertake. As Vandervoort observes, "financial services is moving kind of in a logarithmic increase in velocity... things are ten times faster than they were a decade ago. When you go from three days order to settlement or trade to settlement to now under two hours trade to settlement, if I'm doing nightly reporting, I'm way out of alignment. Whereas ten years ago, that was three times faster than the speed of the pipeline. Today, you the ability to run awry in risk, terms, and exposure terms has been seen multiple times in the industry in recent years."

For companies seeking to increase agility and be more responsive to these highly competitive markets -- not just in financial services -- the combination of SOA and BPM can break down the constrictive silos that cut off essential data and processing resources.

____________________________________________________________________

Posted by joemckendrick in Business Process Management • Data Management • Event Processing • Management • SOA • SOA Events  |  Permalink  | Comments (0)  | TrackBacks (0)

Behold the zebra in the wild savanna -- when a it senses the presence of a lion, it knows to run away, as fast as it can. When it senses food supplies, it knows to act.

Do today's companies have this much situational awareness, and an ability to act quickly to survive and thrive? Not yet, but thanks to new approaches such as complex event processing, they're getting there, according to Gartner VP Roy Schulte. "We can teach computers to do what a zebra does," Roy said. "To collect and process event data to respond quickly and effectively."

In his keynote kicking off ebizQ's recent Event Processing virtual conference, Schulte broke down the essential pieces of complex event processing, and describing how businesses can leverage CEP, or being able to act, in real time, on multiple streams of event data flowing in from different parts of the enterprise. "The value of complex event processing, overall, can be summarized as improving situation awareness. Simply put, that is just knowing what is going on, so you can figure out what to do." The benefits of complex event processing, Schulte said, include better decision quality, faster response times, reduced information glut, and reduced costs.

Schulte defined a business event as a "meaningful change in a state that is something that is relevant to the business. Examples include depositing or withdrawing money from a bank, submitting a purchase order, or hiring an employee." There is also a second term, "event object," that describes how the event is packaged for processing, typically as an XML document these days. "We have to record events using event objects so computers can receive them and do computations on those events," Schulte said.

However, while all companies have always been event driven -- with millions, if not billions, of events in a single day, most events are still handled manually, by people, not computers. "At any one second, a large company has on its network anywhere from 10,000 to 10 billion business events," Schulte explained. "At the low end, that's almost a billion events per day -- at the high end, that’s almost a trillion events per day."

The challenge is that most of the stovepiped and legacy applications that power enterprises are not yet event driven, Schulte observes.

But there's great practicality in automating the ability to capture and make decisions on multiple event streams coming into the core business systems, Schulte says. "For example, you can have a complex event that says, ‘this mornings sales were 30% above our daily average.' That of course is much easier to digest and act on than sending a person 500 detailed sales records, and making the person compute what happened that day manually."

The growing array of sensors, such as RFID tags, combined with front-end systems such as business activity monitoring (BAM) dashboards make complex event processing a reality with today's technology, Schulte points out.

"In many cases, the complex event processing system Is just a front end being used for decision support. The output of the CEP engine is sent to a person through a BAM dashboard, or through an alert such as email or SMA or an Atom or RSS feed. in this case, we have a two-stage computation. In the first stage we’re using a computer to narrow down the data. And in the second stage, we still have a person involved to do the final analysis.

"An application system, or some other device or some other system, detects the event, and generates a message or a notification that is sent to a person. That notification is the event object or event report sent in the form of a message through message-oriented middleware, RSS, a Web service, or an email, or some other communication mechanism. The response to an event may be a manual activity, done by a person or it may be a SOA service or business process or some other application."

However, things could get interesting as CEP systems develop, Schulte added. Namely, the need for human processing could be taken out of the equation all together. "We can bypass that person entirely; we can build enough smarts into the complex event processing engine to determine the specific response that is needed."

Schulte provided a working example of complex event processing in action within the airline industry:

"In large airlines, there is an event oriented middleware that... acts as an enterprise nervous system. Information from hundreds of sources, including sensors on board the aircraft, information coming in from the FAA, and information coming in from standard systems is sent to the enterprise nervous system, and is temporarily stored in event databases. It helps to create the data, the outgoing alerts and notifications that is sent to hundreds of applications on the consuming side to respond to threat and opportunity situations as they emerge. By having information quickly, each of these systems in their respective departments can respond faster. ...Information helps the fueling and maintenance management applications to change their schedules and so forth. By using an event based system, the turnaround time of each plane can be shortened… Fewer airplanes are needed to handle the same schedule."

______________________________________________________________________

Posted by joemckendrick in Business Process Management • Data Management • Event Processing • Management • SOA • SOA Events • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

Oracle's Dave Chappell has always done a great job of linking SOA efforts to measurable business results, and he recently posted an account of a busy online service that was able to integrate its widespread base of customer systems into a well-integrated service layer.

Move Inc., a growing online real estate provider, had what Oracle's Dave deemed a "tall order:" consolidating disparate applications across two business units into an enterprise CRM solution that could provide a single, accurate view of customer data to improve efficiencies and automate auditing, billing and fulfillment processes.

Move Inc. (formerly Homestore, Inc.) provides information on real estate property listings (homes and apartments), moving, home and garden and home finance through its network of online sites, which includes www.realtor.com, www.welcomewagon.com, and www.moving.com.

Tall order indeed. As Dave describes it, Move had systems and touchpoints all over the map. CRM applications were built on .NET, and there were numerous disparate systems and manual touchpoints built to support various business functions for CRM.

The company developed a SOA that focused on re-usability of services, with business processes were at least as efficient if not better than what the current systems offered. Using standard WSDL interfaces, Oracle BPEL PM and Oracle ESB were used to extend the reach and normalize the integration across Siebel CRM, PeopleSoft Enterprise Financial Management and other systems both internal and external

The consolidated customer database is intended to provide support for existing sales activities, order capture, integration with fulfillment systems, integration of customer usage from Web sites into Siebel, and integration to PeopleSoft Billing. The solution involves the use of BPEL, Web services, ESB Mediation, application adapters, and canonical data models.

The project took six months to implement and deploy, Dave reports -- actually, pretty good timing for such an effort. Move was able to achieve both quicker and real-time integration across these systems, and saw a reduction in cost of ownership on existing applications.

"It's always great to hear about successful adoption of SOA, and its particularly exciting when its being used for what you'd think," Dave remarked.

______________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Everyone considers their systems to be "special" in many ways. They represent years of planning, installations, and modifications. However, sometimes "specialness" can get in the way of the ability to deliver agility and flexibility to business clients.

At the recent Tibco TUCON users' conference in San Francisco, Allstate's vice president of technical solutions, Anthony Abbatista, described how his company managed to automate most of its systems and processes in the 1960s and 1970s with what was in it's time a new generation of "special applications." Everything from policy administration to underwriting was captured on the company's array of mainframe computers.

Of course, application designers in these first waves of automation could never have imagined the uses that their systems would be getting nowadays. They never could have envisioned parts of these systems being opened up to the world via the Web.

These systems, Abbatista explained, were all hand-crafted and hand-coded. Commercial off-the-shelf applications just didn't exist in the 1960s and 1970s. However, the Allstate commitment to rolling its own applications continued right up to recent years. At Allstate everything was custom-built, "and we were proud of that," he said. "everything was very 'special,' with limited reuse."

Adding to the complexity and inflexibility, the company had a plethora of systems and vendors for the commercial solutions it did start buying. "Up until five years ago, we never met a software vendor we didn't like," Abbatista said.

The company, which now has $156 billion in assets and 17 million customers, always had plenty of resources for information technology. However, the company needed more responsive and agile IT solutions to succeed in an increasingly competitive environment for the insurance industry.

"When I first arrived at Allstate, we had three to five different integration platforms," Abbatista related. "We had an executive IT board that mirrored the military model, run by 'generals.' We had an abundance of point-to-point integration."

Allstate knew that it needed to embark on a more consolidated, service oriented architecture if its systems were to continue to deliver value.

Areas being modernized include claims processing, which was spread across nine different mainframe-based silos tied together by custom-built middleware. The company employed a standard enterprise service bus to handle claims processing through a single interface across the entire enterprise.

Another initiative was to establish a common integration layer for the company's fast-growing data environment. "Our data hubs are growing 30%-40% a year," Abbastista said. The company also pared down its vendor list to a "handful of strategic partners," numbering 12 to 15 vendors, he said.

Changing the organizational culture was another challenge, Abbatista remarked. "We had to make a substantial commitment to technology, skills, and also selling integrated teams that we had a better approach," he said. SOA governance was also tied to the operations of the procurement organization. This helped provide better visibility of available services, as well as increase reuse, he said. "How many error-logging services did we really need?" he asked.

______________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA • SOA Events  |  Permalink  | Comments (0)  | TrackBacks (0)

Does your SOA initiative remind you more of the gunslinging, saloon-brawling days of the Wild West than of the intrepid pioneers?

Don't feel bad -- most companies are still struggling to tame their Wild West SOA frontiers. The right approaches and solutions can help keep rogue services at bay, while delivering greater value from reusable assets.

I will be joining Christian Hastedt Marckwardt, solution marketing director with SAP, on Tuesday, April 29, at Noon Eastern Time in a special Webinar to discuss the results of a new ebizQ-SAP survey on SOA governance trends and practices.

The survey explored the depth of SOA and SOA governance at organizations. Be sure to join us for a compelling hour, as well as receive a complimentary copy of the complete survey results!

______________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Events • SOA Research and Analyst Reports • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

There's been quite a bit of debate in the industry about whether SOA can deliver reasonable ROI within a reasonable timeframe. The consensus has been that it's going to take time, even years, for the benefits of SOA to take effect.

However, there are exceptions to every piece of accepted conventional wisdom. In the case of mergers and acquisitions, the payback from service-oriented architecture sometimes can be seen in a matter of months.

Tony Baer, who also an ebizQ contributor, has just posted this account at Manufacturing Business Technology, describing how a recent acquisition doubled Mohawk Fine Papers' manufacturing network doubled to six sites, and distribution network quadrupled to four warehouses.

From past experience, Mohawk's IT team knew how painful custom development and integration could be. As Paul Stamas, Mohawk's VP of IT, told Tony: "The biggest problem was managing all the interfaces. The failures in the previous integration were point-to-point connections that nobody owned." So Mohawk took a new tact -- SOA.

The company integrated its existing BPCS enterprise system with the Infor ShipLogix transportation management solution deployed recently to replace an older Logility application. And with a much larger production network, Mohawk also sought to tie BPCS into its Infor Datastream enterprise asset management system. (Note: BPCS was created and marketed by SSA Global, which was purchased by Infor in 2006. But just because a vendor is acquired doesn't make it any easier for a company to integrate the separate products.)

_____________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Dave Rosenberg, CEO of MuleSource, works with a lot of organizations that are starting their SOA journeys, and noticed that many make the same mistake: they spend all their time worry about the technical details of their implementations, but don't pay enough attention to governance.

In a new post here at ebizQ, Dave outlined what he sees as the five greatest mistakes in SOA governance:

1-Decentralizing common artifacts: "When common artifacts such as WSDLs, schemas or configs are scattered in various locations, organizations waste time searching for interfaces and schemas," Dave says. "This is because they lack a central authority for the published service interface, which discourages discovery and reuse across an enterprise."

2-Reinventing the wheel: Perhaps the biggest problem SOA was meant to correct. "Services and applications are often written again and again to perform the same function," Dave says. "As a result, many different versions of the same artifact are built and integrated, increasing development times and creating a huge maintenance cost burden." The solution is a centralized repository or registry available to the enterprise.

3-Hoping for best practices: "Developers may not inherently know best practices, and even if they do, they may not follow them every time," Dave says. Best practices can and should be enforced as enterprise-wide policies, anywhere from the build to the registry to people and processes.

4-Forgetting about service consumers: It is important to continuously be aware of how a service is being used by the final consumer at the end of the process, Dave says. He recommends adopting tools that track dependency management.

5-Inconsistent application deployment strategy: "Many application deployment strategies are ad-hoc, not well documented, and only understood by one person," Dave says. A registry and repository can help automate developer actions, and thus ensure consistency.

How far along are most organizations with their SOA governance? ebizQ recently conducted a survey on SOA governance trends, and I will be joining Christian Hastedt Marckwardt, solution marketing director with SAP, on Tuesday, April 29, at Noon Eastern Time in a special Webinar to discuss the survey results and implications. Be sure to join us for a compelling hour, as well as receive a complimentary copy of the complete survey results!

______________________________________________________________________

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

According to a report in ComputerWeekly, consumer goods company Proctor & Gamble is working on an ambitious service oriented architecture that will provide aggregated data for the company's 32,000 managers.

To accomplish this, the company will be re-using up to half of its internally developed code across the organization, which will be made available as shared services across the enterprise.

The company has already rolled out SOA to 2,000 users, helping to achieve up to 25% of reuse, Terry McFadden, associate director for enterprise architecture at P&G.

_____________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There's been a lot of debate and discussion across the industry as to whether SOA can deliver value to the business early on, or if its more of a long-term process.

For one company working with SOA methodologies for the past 10 years, there clearly has been a long-term benefit, in terms of economies of scale. The earliest services may have not been more cost effective than standard applications, but as SOA and reuse grew, these services grew cheaper and cheaper to use and administer.

Then again, a $5 billion logistics and trucking company ought to know plenty about economies of scale. It may cost $1,000 to ship one refrigerator from New York to Los Angeles, but cost a penny if it's intelligently bundled with another shipment. Why not apply this know-how to its information technology infrastructure?

One of the best and earliest examples of heavy-duty implementations of Web services and SOA is Con-Way Inc., a logistics and trucking company. I first spoke with them and documented their efforts back in late 2004. At the time, Con-Way had already been evolving an SOA infrastructure for several years, enabling its seven separate business units to share standardized customer-facing applications. At that time, Con-Way had about 20 coarse-grain business components, such as a shipment component, purchasing component, and customer component.

SearchSOA's Rich Seeley just spoke with the folks at Con-Way, and, needless to say, the company has come a long way since 2004. For one, revenues at the freight transportation company were only making a measly $2 billion when I last spoke with them.

Shibashis Mukherjee, Con-Way lead enterprise architect, told Rich how things came about, dating back to the 1990s, when the company embarked on a component-based methodology to expose COBOL mainframe applications as services. The company began building various Web services earlier this decade.

Con-Way set out not knowing how much services would be reused -- but this was very much their design goal. . "When we built services at that point in time, we built every piece of functionality as a reusable piece of code," Mukherjee said. "We had no idea whether it was going to be reused or not." However, reuse across the company's various business lines took off.

The result was a multiplier effect as SOA gradually took hold in the corporate culture. "It took a couple of projects to see all the benefits," Mukherjee said. "You don't generally see the benefits in the first project you do. We also had executive management buy-in and we had a long-term vision. So as project after project is done, our development time was cut as we reused components built by the previous projects."

______________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Business-IT alignment... Has a day gone by over the past ten years that we have not heard that phrase?

While it seems to be a constant but elusive dream -- like peace on Earth -- some companies indicate that SOA may be moving them closer to reality.

Fellow ebizQ colleague James Taylor, out at the IBM Impact confab this week, provides an account of an end-user customer panel on the ever-vexing challenge of business-IT alignment. Is service-oriented architecture helping to bring about some of this alignment?

A panel of corporate practitioners talked about their SOA efforts, and the impact SOA was having on alignment -- a positive impact, by the way. James reports that Randy Wallace from Michelin said one of his company's biggest challenges is "B2B with lots of billers to interface directly in their order management systems so, for instance, allow dealers to integrate orders with Michelin. They are currently evolving their order-to-cash system using Process Server and SOA."

Who much alignment has Michelin seen? According to Wallace, the company has come a long way, "from having a very small percentage of IT spend aligned with key business goals (6%) to one that is much more so (81%)."

That's pretty impressive. Wallace cited some examples: "For instance, in the past business units in different regions picked i2 and Manugistics at the same time and both were implemented resulting in separate systems. A stronger governance process and overall architecture are now established, driven by business ambitions and regularly updated. Far fewer and more focused projects as a result. Senior executive user satisfaction has risen steadily."

Austin Waldron from Health Care Services Corporation (HCSC) said his company's "focus is on using SOA in legacy modernization where many disparate systems are being replaced by a unified set of shared services. The governance issues seem to have been key for HCSC."

Waldron also talked about moving closer to business-IT alignment. "They had some years of IT spend focused more on basic IT infrastructure (security, robustness etc) but now investments much more driven by the business strategy."

Another panalist talked about more alignment at the front lines of the business. Jeff Auker from The Hartford "talked about challenge of consumer front-ends. Consumers working directly with The Hartford now expect a much more interactive online experience for sales and service - this is being driven by GEICO and Progressive’s campaigns. SOA is key because they have some front-ends that are tightly integrated with very old back-ends and SOA let’s them decouple them."

Thanks again to James Taylor for this report .

______________________________________________________________________

Posted by joemckendrick in Business Process Management • Case Study • Management • SOA • SOA Events • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

I recently had the opportunity to host an ebizQ Webinar on managing SOA performance with Forrester's Randy Heffner and AmberPoint's Ed Horst.

SOA has a lot of moving parts, and digging down to spot the root cause of a service problem is not always easy. SOAs are multilayered creatures. Is it the service itself that's creating an issue? Is it the database? Is it one of the servers?

As Randy put it:

"We’re talking about managing complex SOA services. So we’re diving into an advanced topic that comes up as you realize how deep your service implementations can go, and as you realize some of the dependencies that happen between the various components behind the implementation of your service. Your SOA management solution however you construct it and buy it must handle SOA-based service requests that have complex service implementations."

Randy says when troubles arise with services in SOA, it's often a challenge to pinpoint the source of the troubles, and a number of teams may get involved in the process of identifying issues -- and not have the big picture. Now, Heffner says, "great, we’ve identified there’s a problem with a service, who we going to call?" With complex SOA implementation, and multiple teams, the only answer that will be coming from everyone within their respective teams saying, "it's not me -- my stuff is working fine." That's because everyone has a view limited to their piece of the infrastructure, Randy says.

SOA management tools need to address "deep service" management, Randy pointed out. SOA management tools all do a fairly good job of altering administrators to problems with a service. Even in a complex service implementation -- it could be Java, .NET, messaging middleware, or legacy connectors -- when trouble is afoot, a good management tool will do a good job of sending an alert out.

Randy urges configuring SOA management strategies and solutions to conduct "deep service management." Typically, SOA management solutions employ solutions that don't look beyond the SOAP interface. A new generation of tools that are emerging, however, that can look beyond the service interface to the databases, services, and messaging layers beneath.

SOA management should be able to handle a variety of SOA deployments, ranging from services that invoke Java Message Service, MSMQ, Java RMKI, or CORBA, to ESBs or app servers. Many deep service SOA management approaches can start with agents that many SOA management solutions provides, Heffner said. Then, there are also an increasing number of management solutions that run natively on various platforms.

They key is to employ these solutions -- with or without agents -- to gain better visibility into the systems behind the services, he said. "SOA management solutions may have various ways to construct or correlate a picture, such as dropping tags into a message... or, you might have to do a little work in the configuration..." As services arise, problems will be better isolated, and administrators will know which team to call for assistance. Such deep service management also delivers benefits beyond root cause analysis, such as capacity management.

Randy makes the following recommendations for achieving deep service management:

"Formulate your SOA management strategies; how you’re going to do successful SOA management before you start thinking about products to do SOA management.... You have to deeply know the technologies, know how complex your implementations are. Will your SOA solutions will be able to help you manage your services across the technologies? Will your SOA management solution be able to tie together the complexity and correlate the complexity?

"...Build deep SOA monitoring and management into your whole overall SOA management. It has to do with the design of your architecture, and all the elements that are part of the implementation of your services, and everything that's behind your service interfaces. Build deep service monitoring criteria into your product selection criteria as you are selecting SOA management solutions. ...Think in terms of orchestration engines, integration products, application servers, SOA applications, repository, and SOA management. Think of them and SOA management as one cohesive SOA management platform.

"So you need to understand the relationships and connections. The bottom line is to think about deep service management as you’re pursing your solution."

_____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Events • SOA Podcasts • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

Everyone talks about how SOA is reshaping the roles and priorities of developers, but how much change can they really be seeing? Maybe the real big changes are happening elsewhere up the food chain.

SearchSOA's Rich Seeley recently spoke with John Michelsen, chief scientist at iTKO, who pointed out that thanks to SOA, "no job is being more radically changed than that of business analyst."

Ironically, developers may see the least impact of anybody from SOA. As John puts it:

"I think it might be fair to say that the individual developer writing code is the least affected because he or she is taking requirements and building a component, testing components, and plugging it into a larger system. That in itself is not that different than it was five years ago. So, ironically, the developer may be the least impacted by SOA."

So what did the business analyst do, exactly, before the advent of SOA? Essentially, they created requirements documents for developers to follow. Usually, in John's words, it was a "Word document filled with 10 Commandments-style 'the-system-shall' statements and screenshots illustrating the functionality end users required."

Now, with SOA, business analysts need to learn to work with business process modeling tools instead of creating 300-page Word documents, John said.

But it's all good, he added.

New business process modeling tools on the market even enable business analysts "to describe processes in business language rather than in IT jargon." In the process, since business analysts now have to describe the overall business application that is being built from the services, this is forcing greater alignment between IT development and the business.

And, after all, isn't that the name of the game for SOA?

_____________________________________________________________________

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

EbizQ has just posted a transcript of my recent Webcast with IBM's Leif Davidson is now available for perusal.

Some highlights of our discussion:

Leif Davidson on how SOA always starts off with good intentions, but...

"The past history of the whole IT business has shown what happens when there is no control, you know, as we talked about earlier in terms of creating rat’s nest. Everybody, you know, no one comes in with the intention of how can I make things more complicated and less flexible. Everyone starts off with good intentions and, you know, an SOA project whether it’s done by one team or, you know, 21 teams in a business could be done with the best intentions but could end up the with a mess."

"And I think SOA’s particularly that way if you think about what it actually means in the business sense; these composite applications, invoking services from across and beyond your business. If you don’t actually have control from the very early days of SOA, you’ve now got a much more dynamic flexible business and much more dynamic and flexible access across your business to your IT. If you don’t have that sort of sense of control and ownership and governance its probably the right word, then I think you do risk much more than in a traditional IT infrastructure."

Yours truly on impending SOA growth:

"We find [in our survey of 244 companies] that organizations are really ramping up their SOA initiatives. There’s going to be a lot of steady growth for SOA. We actually looked at companies -- we actually looked at the number of services, the number of enterprise services being shared or reused. They intend to deploy large numbers of services. By next year this time, according to what our respondents are telling us, those companies with more than 25 services will jump dramatically, the percentage of companies from 24% to 39% over the next 12 months."

"The growth -- this growth in businesses that are crossing this threshold into multiple critical mass of services, 25 or more services is a significant number because once they cross this threshold they need to start treating SOA as a critical strategy and need to address -- start addressing many aspects, the management, and policy enforcement aspects, for example. Connecting up their mission critical services becomes an important priority."

Leif on federated ESBs:

"A Federated ESB is really a logical step from what we’ve talking about having separate ESB’s to meet different departmental and project needs. As you see on this chart any different department may have its own ESB but that doesn’t actually get away from the needs for all of those ESBs to deliver common capabilities but by the integration across different departments. And so the Federated ESBs really allowing businesses to select multiple different ESBs but allowing them to work together to provide common capabilities across that disparate infrastructure.

Click here for the Webcast; here for the transcript.

____________________________________________________________________

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

Yes, as we've been preaching incessantly on these pages for the past couple of years, governance does make the difference between SOA success and ending up with Just a Bunch of Web Services, or JBOWS.

In a new ComputerWorld report, Carphone Warehouse, a mobile phone retailer based in the UK, credits a new design-time governance system with boosting the adoption of its SOA effort, now in its third year.

The company was experiencing many of the issues that occur with JBOWS architectures, such as creating duplicate services, and resorting to time-consuming manual checks of services. More than half of the service designs were not in compliance with corporate standards.

The company recently acted to remedy the duplication and confusion by putting an automated governance system in place. Right away, things started falling in place. For starters, 95 percent of the service designs now being put into production conform to governance standards, according to Pawel Maszczyk, enterprise architect at Carphone Warehouse.

Even better, the article relates, by avoiding accidental duplication of services, the automated governance system (from HP Systinet) is projected to deliver savings of £526,000 over three years. Another £93,750 will come from time saved managing governance, and £113,500 from time saved reviewing services. That's a total of £733,000, or the equivalent of US$1.5 million at the current exchange rate.

“We gained visibility. If you’re looking for a service that does something in particular, you can identify it and reuse it quickly," according to Maszczyk. “It also automates processes, so we know if there is a change to approve. Before, we had to go and find out if there was something that we needed to do. It automatically carries out mundane checks so we can launch new services more quickly.”

The company plans to put automated runtime governance in place as its next goal.

As always, Maszczyk pointed out, the organizational issues are the most vexing in moving SOA forward. Adopting SOA also means adopting a new “mentality” on IT, he said. “It’s not an easy change. You have to explain what you’re trying to achieve."

If the organization sees SOA evolving rather than JBOWS, it's much more likely to sign on to the effort -- perhaps even with greater enthusiasm.

_____________________________________________________________________

Posted by joemckendrick in Case Study • Management • SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There's no such thing as a single enterprise SOA. At least not yet.

I just had the opportunity to co-present a Webinar with IBM's Leif Davidson on the topic of "Identifying and Federating Today's SOA Power Centers," in which we explored the results of a recent ebizQ survey of 244 companies.

The survey finds that there's no question that enterprises are firmly committed to service oriented architecture as a strategy going forward - and they're willing to put budget dollars into the endeavor.

But the survey also shows that there's no such thing as a single, all-encompassing SOA effort that covers every service initiative from every corner of the enterprise. Rather, most SOA or enterprise service efforts are "islands" of integration that arise within individual business units, designed to address specific problems.

The challenge is that these separate SOA efforts have different formats and technology foundations under development or implemented within their walls. Many use application servers to support enterprise services, others leverage composite applications on middleware, and others rely on enterprise service buses. In fact, the survey showed that enterprises are taking multiple approaches to building and supporting SOA, including application servers, composite middleware, and enterprise service buses.

The survey also found that most of these service deployments aren't yet interfacing with mission-critical systems. But this is changing rapidly, as the number of services designed for reuse proliferate. The survey finds steady, unrelenting growth in organizations maintaining large volumes of SOA-based services - the number with more than 100 services in production is expected to double.

The bottom line is that there is no single approach to SOA. SOA requires a mix of solutions but the eventual result should be a more reliable, simple and flexible infrastructure and business.

There are two interconnected levels to addressing the problem. First, on a technology level, is federation. One out of four companies have already moved to a federated infrastructure to support multiple instances of ESBs or intermediaries. The survey also shows that those with federated infrastructures are more likely to be able to move from siloed SOA to enterprise-scale SOA.

Then, on a business level, there's governance. Effective governance will make the difference between ending up with a tangle of services -- JBOWS -- or a functioning SOA that truly supports business endeavors at any endpoint across the enterprise. The survey finds that organizations recognize the urgency of governance, but a surprisingly large percentage leave this up to the IT department.

The Webinar in which Leif and I discuss the implications of the survey results can be found here at the ebizQ site. (Registration required.)

____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Events • SOA Research and Analyst Reports • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

Everyone is talking about "SOA governance" these days, but what does it all really mean?

At what stage are most SOA governance programs at? What are organizations trying to accomplish with these efforts? How are policies enforced? Are companies tracking reuse? Are companies employing automated enforcement, or is this still a pipe dream?

ebizQ is conducting a new survey to answer these questions and more, to better gauge where companies are at with efforts to better manage and govern their SOA deployments.

Forty iPod Shuffles will be given away to survey respondents in a drawing, to thank you for your input into the brief questionnaire. In addition, you will also receive a copy of the survey results, which will help you assess where your company stands in relation to others in managing and governing SOA.

The survey, which only takes a few minutes to complete, is posted here at ebizQ. Hurry, the deadline for responses is this Friday, March 14.

_____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Research and Analyst Reports  |  Permalink  | Comments (0)  | TrackBacks (0)

For years, the disciplines of enterprise integration -- followed by SOA -- have always been perceived as "hard and techie." This has made discussions with the business process management (BPM) side of the house difficult.

Now, thanks to the introduction of new lightweight approaches via Web 2.0, SOA, BPM, and integration are now becoming more flexible, user-driven methodologies.

David Linthicum recently spoke with Dr. Dale Skeen, founder of Vitria, a well-established integration vendor, about this shift. (The podcast is here, and a transcript of Dave's discussion with Dale Skeen is available for viewing here.)

This is part of SOA moving into its next generation -- "the next great leap going together is really leveraging three very important technologies in the enterprise -- SOA, BPM and Web 2.0," Dale said. While these three areas are seen as separate technologies or methodologies, Dales sees their inevitable convergence into what he calls an "enterprise platform."

First of all, Dale said, SOA and BPM have always been a natural pairing. "SOA is an enabler that allows you to access business functions, and services, and data universally. BPM is a higher level that orchestrates these business services and human interactions in ways that allow you to meet a business objective. So hence, I've always considered these to be the perfect complementary technologies to work together."

Now, Web 2.0 is bringing SOA-BPM closer to the end user, Dale said. "SOA brings this universal access to services and data through the SOA enablement tools. It does in a secure, manageable, and governed fashion. Now, Web 2.0 brings rich internet interfaces, rich user experiences based on technology such as AJAX and Flex, which are universally available in your Web browser."

"Application integration is hard, and very techie. Web 2.0 allows this notion of mashups where you let users sort of integrate in a flexible, lightweight, easy-to-do fashion."

These are all new trends that are shifting IT empowerment to the business end user, Dale added. "Simple things like mashups, we're talking visual layering of information, we're talking about collaboration technologies such as instant messaging. All of these have a role in enterprise software. And actually, the introduction of that can be very exciting for both the IT and the business side."

IT professionals need not fret over this shift, however, Dale said. "It means that IT will be able to do faster technology upgrades because of that, they have more control over the server aspect of it, and the client side they don't have to worry about. They're going to be able to lower the support costs and it also brings fundamentally new deployment models such as Software-as-a-service, which we think, is going to be a fundamental part of business IT going forward."

_____________________________________________________________________

Posted by joemckendrick in Business Process Management • Data Management • Enterprise 2.0 • Management • SOA • SOA Podcasts • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

This Wednesday the 12th, IBM's Leif Davidsen and I will be delivering the results of and commentary around ebizQ's latest survey results on SOA and trends toward ESB federation. (To sign up for the Webinar, click here.)

To help build the conversation that will be taking place within the Webinar, we invite you to join in with any questions or observations you may have.

One inquiry focused on the viability of Web Services Description Language, or WSDL,in a federated environment. Would exposing ESBs as a WSDL be sufficient to link different vendors' ESBs together?

Leif responds that while WSDL can help make the connection, but more is required for a robust SOA infrastructure across business units. "To make the most out of an SOA infrastructure, resources should be used and reused across the business. This will drive the connection of these ESBs to provide end-to-end seamless connectivity," he said.

"From a purely functional point-of-view a service provider and consumer can connect using a WSDL interface. But when looking at the business perspective, important issues such as Governance, Security, Transactionality and Systems Management come into view. In order to invoke the services through a WSDL interface, the service needs to be located. If it exists in a remote system, the security credentials need to be passed along. Updates to transactions add to the complexity and criticality. And of course not every asset is exposed as a Web Service."

"So while WSDL maybe a part of the solution for connecting web services through different ESBs, there are many other aspects to consider other than simple web services connectivity that will be important to businesses when considering the implications of actual deployment."

Join us Wednesday an Noon Eastern Time for the latest data and solutions in managing multiple SOA implementations in our Webinar, Identifying and Federating Today's SOA Power Centers Through Enterprise Service Buses.

_____________________________________________________________________

Posted by joemckendrick in Management • SOA • SOA Events • SOA Research and Analyst Reports • SOA Vendors  |  Permalink  | Comments (0)  | TrackBacks (0)

At Delta Airlines, SOA is cutting the cost of ownership by half for its various applications and systems. That's good news, of course, but the company's experience with proactive governance also provides some valuable pointers for other companies wrestling with the politics of SOA.

Delta's SOA has been under development for more than 10 years and is now its third phase, says Bret Martin, principal enterprise architecture for Delta Technology Inc., a wholly owned subsidiary of Delta Airlines.

In a session (registration required) at a recent online conference put on by Tibco, Martin said that phase one of what the airline calls its "Digital Nervous System," or DNS, commenced with proprietary and home-grown integration hooks in 1996. As SOA and Web services evolved earlier this decade, Delta focused on bringing DNS in line with industry standards such as SOAP over HTTP, delivered through an enterprise service bus at the back end.

Now, in the latest phase of the effort, the goal is to see that "SOA is infused with the enterprise," Martin related. "SOA is a way of life for implementing business applications across the enterprise."

The greatest value Delta is seeing from SOA is reuse of IT assets and data, Martin pointed out. "Reuse is one of the big drivers for our SOA environment," he said. Delta's SOA, for example, is reusing the same customer and operational data across a range of systems, from the Delta.com Website to ticketing kiosks to ticketing counters and gate systems. "It allows check-in to happen in a uniform way," he explained. Another way services are being leveraged are by exposing services to vendors and partners, such as American Express or operations companies.

Delta engaged a cross-enterprise governance team to perform all the tasks that are expected from an SOA governance group: managing registry and repository in making sure that services are registered, defining the policies that are going to go into the deployment of a service, defining security, defining service-level agreements.

However, Delta recognized the value that the governance team was bringing beyond merely approving, registering, and managing services, Martin says. "Its not only registering services, but also trying to promote services that we already have defined, and have already put into production." This is essential, he said, because developers and architects aren't necessarily aware of what services are available out there, or where they can be found.

"What we needed is a governance organization that says they can help, 'here is a SOA business process, and is is how it can be implemented," says Martin. "Having a group that stands in front of those services, and matches business requirements to the services that we have… is a huge benefit."

Posted by joemckendrick in Business Process Management • Case Study • Management • SOA • SOA Events  |  Permalink  | Comments (0)  | TrackBacks (0)

In his latest post, ebizQ analyst Peter Schooff spoke with Anne Thomas Manes about the insecurity that continues to nag at SOA. (Transcript and podcast link here.)

This is an issue that's not getting near enough attention, Anne points out. Ironically, securing SOA is not a big deal, as it employs the same mechanisms used to secure Web services and Websites. Actually, Anne pointed out, "at this point, I think it’s really easy to secure your environment. You just have to use different practices than what you would probably do just for your Websites... Any platform that support Web services has the ability to support WS-Security."

And, as with Web services and Websites, applications or systems may be vulnerable to outside intrusions. "With services, you’re exposing business processes within your organization," Anne says. "If you don’t properly secure those interfaces to those business processes, you’re now letting anybody in the world come in and access them." Too many companies think that having those services contained within a well-protected firewall will do the trick. But, as she points out, these are intended to only protect point-to-point connections.

"If there is a URL that provides access to a service, chances are somebody’s going to be able to connect into it," Anne cautioned. "And the -- the idea that your perimeter is actually going to protect your internal systems is pretty dangerous at this point."

What to do? The best practice for SOA security is to enable security to be applied uniformly and automatically across all services deployed or run within the SOA, versus trying to build in security for each separate service.

Anne said that a layered defense will better protect SOA-based transactions and underlying data. "Use a combination of security protections when you’re dealing with a service-oriented system," she said. "You use the traditional periphery type of security measures, you also use identity-based security measures at the endpoints, and then potentially you use additional intermediaries to perform additional security capabilities like auditing, or cross domain, credential mapping and things like that."

Plus, she said, look into technologies from XML gateway vendors or from Web services management vendors "which will automatically protect your services for you, and automatically configure the kind of management and security protections that you want, such that yo