SOA in Action

"There is no easy way of describing an ungoverned SOA." - Mark Greeff

In a new interview, Software AG's Mark Greeff talks about how governance makes the difference between a well-managed SOA and a 'State Of Anarchy.'

Take rogues services, for example. Greeff observes that rogue projects typically aren't registered from a design time perspective. He says that governance controls within an SOA environment should "focus on providing a run-time governance engine to discover these rogue services." Endpoints need to be managed, and sites should "have the ability to have an exchange service model between the run-time world and the design-time world." Rogue services should be detected, and registered back to the design-time platform.

Can an effective governance platform bring IT and the business together? Greeff thinks so. "One of the things that you seen in the whole governance story are that there has been an organizational governance platform -- people have talked about organizational governance for a while," he observes. "What we are doing now is to bring together that corporate governance model and IT governance model into an SOA governance platform."

Effective SOA governance oversight means "being able to analyze and plan projects a lot better and being able to visualize all integration artifact dependencies," says Greeff.

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

A few days back, I opened up a discussion on the convergence of virtualization and service-oriented architecture.

The convergence comes in many flavors. In one sense, SOA itself can be considered the "virtualization" of applications. But the main issue that concerns executives and managers these days is how their underlying infrastructure -- servers, networks, databases -- will hold up as SOA creates unexpected surges in demand.

I like the way Brad Shimmin of Current Analysis describes service virtualization: it's a process "where bandwidth emerges from the mist and vanishes just as mysteriously in response to provisioning rules and service-level agreements."

He also is watching the growing convergence between SOA and virtualization. He describes the challenge this way: "With so much talk recently about automated biofeedback monitoring and business rules within rules, you might think that an enterprise stands as much of a chance of optimizing its service-oriented architecture applications as it does launching a Saturn V rocket. And you'd be right."

While virtualization has actually been around for some time, SOA adds a new urgency to the mix. The "ultimate justification" for virtualization, Brad says, is "that loosely coupled and extremely unknowable universe of reused and often misused Web services."

Announcements from Red Hat and IBM recognize this growing need. All SOA virtualization needs at this point, Brad says, is the ability to abstract "the entire notion of SOA process optimization away from the human element, thereby answering the question, 'should I add another virtual Java messaging server to accommodate tomorrow's anticipated rush on Tickle Me Elmos?'"

As SOAs keep growing in scope and keeping adding reusable services, enterprises are going to start really feeling the pinch on their servers and infrastructure. The more successful your SOA -- meaning there is a lot of adoption of your reusable services -- the more you are going to get pinched. Virtualization offers a way to intelligently handle new SOA workloads without having to go out and buy dozens of new servers.

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

The best request for proposal (RFP) for SOA may be one that doesn't even mention SOA.

ZapThink's Jason Bloomberg recently dove into an oft-overlooked aspect of SOA -- how to prepare a request for proposal from a vendor.

"SOA is something you do, not something you buy," Jason reminds us. Therefore, simply sending out RFPs to a few vendors will not cut it. "Putting together RFPs for SOA initiatives is fraught with perils," he writes. "What precisely do you want the third party to do for you?"

Jason points out the greatest mistakes companies make when issuing RFPs for SOA-related projects:

Confusing architecture with implementation: RFPs should say nothing about the specific technology you might expect your provider to bring to bear... steer clear of any vendor who says that you'll get SOA by buying any specific product."

Trying to do too much: Don't try to put together a "hugely detailed RFP that delineates everything your provider would be expected to do." There are too many unknowns, Jason points out.

Expecting vendors to put SOA advice in their response: Ask for customer references instead.

Expecting to be able to compare proposals via purely objective criteria: "Formal criteria are woefully inadequate for evaluating proposals for SOA-related professional services, because there is so much variation from one organization to another among SOA approaches. As a result, such objective criteria are bound to focus on less important details (frequently technical capabilities), rather than the more important architectural and human interaction skills."

Step by step, one step at a time is the best rule for putting together an RFP, Jason says. And, he wisely suggests, don't even mention SOA in the RFP. "Instead of delineating some approach to solving the problems in the RFP, put your energy into describing the problems and let the provider respond with their own approach for solving them."

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

Is it possible for your SOA to become a victim of its own success? If you have built and maintain a fairly healthy stable of services, and other departments across your enterprise begin adopting (or reusing) your services, your servers could quickly become taxed to the max.

In a new post, Dave Linthicum observes that as SOAs grow in scope, so does the challenge of managing the new workloads incurred on existing servers.

As Dave puts it: "As such many SOAs that I'm seeing deployed have a tendency to be out-of-balance or a disproportionate portion of the processing is taking place within a small group of services, and the others are not pulling their load. Thus, you may have the old 80/20 rule again, with 20 percent of the services handling 80 percent of the processing."

Apparently, the folks at IBM have been thinking along the same lines. The other week, Big Blue announced a set of bundled hardware/software products that address SOA overload through virtualization approaches. (Press release here.) IBM says its virtualization technology can shift around workloads in response to spikes in services activities. Hence, part of the growing case for merging virtualization technologies with SOA.

Dave recommends planning for service balancing early in the process, with approaches such as creating a performance model using the profiles of the services, to get a better understanding of the performance trade-offs of your SOA. "Truth-be-told, sometimes you're stuck, and there is little you can do to move processing from one service to another. However, more often than not your services are 'balanceable' and you should consider how the processes are distributed across services, as well as logical organization of those services."

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

Ann Bednarz, writing in BPM Today, provides a list of 10 best practices for SOA:

1) Start with a process that previously has been opened. In other words, the path of least resistance. Pick a "target system" in which other applications already have their hooks.

2) Don't take interoperability for granted. Just because a vendor says an application meets all the standards doesn't mean it will automatically interoperate with another vendor's application. Every vendor has its own flavor of "standardization."

3) Don't open your wallet too quickly 'Nuff said.

4) Think governance. Let me add, "do" governance. "Building a new framework for an entire corporate infrastructure is no easy task." Being able to understand and facilitate what services and standards are going into the SOA is a good first step.

5) A little incentive never hurts. People are set in their ways. Dangle a few carrots to encourage reuse, and adoption of standards and interfaces.

6) Budget realistically, or buy-in will suffer. Time, not money, is the great SOA killer. "Typically, the time and labor associated with building an SOA -- not the cost of purchasing technology -- can surprise the uninitiated." Dave Linthicum is quoted as saying that a good rule of thumb is to "allow about three or four months for each system an SOA project envelops; with normal complexity, a six-system project will take a couple of years from inception through funding, deployment and completion."

7) Don't skimp on documentation. That rarely ever happens, right?

8) Registries aren't a cure-all. Some commercial registries "don't do justice" to tracking both the technical details associated with services, such as translation requirements and service dependencies, and
functional considerations, such as what processes are involved.

9) Don't forget the network. "SOA is going to add to the load on the network -- it's that simple."

10) Mind your techie talk. Businesspeople won't get it.

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

Service-oriented architecture and enterprise data management have a lot of common ground, but tend to be treated as two separate entities. There are some industry observers who even say a well-designed data model, based on current database and data management technology can already accomplish all the things SOA promises.

However, SOA and EDM have a lot they can offer each other. And it's time that SOA efforts include ways to surface data resources. "Just because a database is buried deep behind a service interface doesn't mean we can ignore the basic principles of data management," wrote Adrian Apthorp in a recent blog entry.

In his keynote at last November's SOA in Action conference, Gartner's Roy Schulte did a great job of describing the parallels between EDM and SOA. EDM, in fact, was conceived long before SOA, but employed the same principles of reuse of a common base of data elements -- a concept picked up by SOA years later. "The theory was if you could have all these applications tied into the database, you could have one copy of the data -- all the applications could share that data." However, Schulte observed, "most companies found that although they did implement relational database management system, and although they did share data across multiple applications, they still could not get to one copy of the data. They still had 20 copies of the employee and the product data. And maybe 40 or 50 copies of the customer data."

Can SOA help bring all that data into a common domain, or will SOA fragment the way the data world has? The jury is still out on that, Schulte said.

Arpthorp said he has seen little discussion of the role of EDM within the service fabric. And he asks a very key question as to how data will be handled in this context: "How do we know that data passed through an interface is handled correctly? ...We cannot rely on a sea of services that are going to perform every validation for us - much of this will still be left embedded in applications. After all how would our services perform if every validation required a service invocation?"

Arpthorp outlined the three key issues in making an EDM/SOA convergence a reality:

Synchronization (including translation) of content: "Ensuring that reference data or master data are up to date and distributed to where it's required when it's required."

Synchronization (including translation) of definition: "As with any language, establishing a single dialect for the business and implementing it in its information systems is probably not a reality, especially when many system components are sourced from outside the enterprise and/or need to interoperate with customer and supplier services. Is Oracle's semantic model the same as SAP's?"

Data (and service) ownership: "Until this fundamental principle of data management is established many of the advertised benefits of service orientation will remain elusive."

Enterprises need ways to cost-effectively access data from any application, running on any system, from any data format. Data warehouse and EDM providers are beginning to offer Web services through which end-users can direct queries and access analytical applications. Such services handle the computation and sifting of data, versus traditional SQL commands. Services run against data can also be components of CRM or ERP applications, and may access data sources and do the analysis to determine a product's success in certain markets, a customer’s profitability, or abnormalities that may signal fraud.

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

Oh what a tangled Web we weave when first we practice to integrate....

My colleague Gian Trotta just conducted an interview with Leif Davidsen, worldwide product marketing manager for WebSphere Application Integration for IBM. (Podcast and transcript posted here.)

Davidsen sees entreprise service buses (ESBs) as the most logical starting point for SOA-based build-outs. But one size of ESB does not fit all. Many organizations are tangled spaghetti-oriented architectures of point-to-point interfaces, adapters, connectors, middleware, and other motley assortments of integration attempts. All through the 1990s and most of the 2000s, companies spent megadollars on various integration approaches, and the expensive consulting fees that went with it.

“What many businesses today tend to have is a real rat’s nest of connectivity links between their existing applications," Davidsen told Gian. He cited the challenges organizations face as a result of all these point-to-point hard-coupled links that they've built over the years. For example, these integration points tend to swamp "the actual business logic that the application is actually there to perform and increasing the cost of changing or maintaining that application." Plus, these spaghetti-oriented architectures introduce "the potential for errors or fragility."

IBM introduces three levels of ESBs that fit the budgets and sophistication of various types of end users. Interestingly, he considers Datapower appliances (IBM acquired Datapower last year) to be a form of ESB, though not in the traditional sense. Datapower devices are designed to manage XML traffic, helping to accelerate its movement while providing additional security. That way, such processing loads can be offloaded from corporate servers. "The DataPower application device is a very different sort of ESB; it’s sort of unique within IBM," Davidsen said.

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

There has been a raging debate across the industry about whether reuse is the value that can be found in SOA, or if it's merely the latest attempt at object-oriented development.

Marcia Kaufman of Hurwitz Group is in the reuse-is-value camp, and goes as far as comparing software/service reuse to the standardization and reuse that happens within automobile assembly plants. "The reuse of IT assets is not so different from the reuse of components in manufacturing," she observes in a recent article. "Automobile manufacturers do not make a different engine for each model of car they sell; they make a small range of engines and install them in a wide variety of models. Once a new engine has been tested and documented, its reuse in a wholly new model gets the new car to market much faster."

That makes a lot of sense, and it makes even more sense to redeploy software and services across different types of applications without reinventing the wheel. However, reuse won;t magically happen when you put those services out there. Effective reuse requires rock-solid governance to deliver value to the business.

Kaufman cites three risk areas that can render reuse as a useless exercise:

Poor process: "Collaboration between business and IT needs to result in the business having a clear understanding of which definitions of data make sense and when to use them, how to apply rules and what level of granularity is appropriate for business services. Effective reuse will be much harder to achieve unless there is a framework in place that ensures that business and IT are singing from the same song sheet."

Poor code management: "When software components are changed then the changes apply everywhere -- often resulting in unintended consequences. A strategy for reuse of business services must include an approval process for changes which begins with the owner of the business service."

Lack of overall control: "What if, for example, each business unit in a transportation services company follows a different process for extending credit to customers?" If the business wants to create a shared business service for this process, it needs to determine who owns the business process and how will changes be controlled.

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

"Those with BPM skills are not typically part of the SOA discussion, and as such their knowledge and connection to the business has not transferred to the organization's separate efforts. What sort of business process knowledge can SOA folks learn from their BPM counterparts, and why are we needlessly separating our BPM and SOA efforts?"

That's the issue raised in a new advisory from ZapThink, which observes that business process management efforts have been successful at aligning closely to the business, something in which SOA is lacking. But the chasm is still too wide between the two disciplines. "The fact that many in IT are unable to justify a business case for a SOA investment signals that there must be a disconnect between the problems the business wants to solve and the promise of SOA as a solution," ZapThink said. "Yet, this is not the case with all IT initiatives. Indeed, the area of Business Process Management (some would add Modeling and Monitoring to the collective BPM term), has little role within the organization unless it is maps to specific business processes."

ZapThink notes, however, that there is a wide gulf between the BPM and SOA communities. "Many in IT who now champion SOA are not conversant in the language of business process. They often lack skills to do proper business process modeling and have not been involved enough in the organization?s BPM efforts to learn the benefits and pitfalls of various BPM approaches. The problem is that traditional integration experts are not the same as the business process experts."

Well-established BPM methodologies need to be brought into the SOA realm, ZapThink says. "Proper process-driven SOA considers BPM to be the top-down portion of any iterative SOA methodology with the result of well-defined Service contracts and a methodology that enables continuous, iterative definition of both the processes and their representative services." BPM experts should also be included in SOA teams.

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

SOA is more than tying together back-end systems. It can also serve as a strategy to advance a unified communications platform that enhances the customer experience.

Dana Gardner provides this account of the Seaport Hotel's in-room "Seaportal" application, built using SOA principles to attain a true IP convergence features. The hotel pulled together VOIP, unified communications, SOA, Web services and external information sources — all with a touch-screen interface for the hotel's guests. The touch-screen terminals run on thin clients with Windows Embedded XP.

"Seaportal may well define the next generation of hotel-based communications and information access services," Dana writes. "It also helps the hotel monetize its services better (now that making money from phone calls is history). It newly empowers guests and traveling business workers to get what they need quickly and easily in terms of information, access, unified communications and entertainment."

Business intelligence plays a key role here. "When guests access their needed or desired services from the portal, that use pattern can be tracked and examined," Dana explains. A guest's individual preferences can be observed, measured, and therefore enhanced, either on this trip or the next. "Before such use was scattered amid different communications functions and networks, and hard to capture and measure."

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

You would think that a large vendor that sells SOA solutions would have no issues implementing said solutions across their own enterprises. But, alas, getting employees to eat your own dogfood is just as challenging as selling solutions on the open market.

Rich Seeley provides this account of SOA implementation at Sun Microsystems -- in which the vendor's SOA team had to sell the concept to its business users.

Sound familiar?

"It's hard to go sell SOA within the company," said Mike Ricigliano, senior manager for integration services
at Sun. "People go, 'Well isn't this just another reuse. Where's the hard ROI here?'"

Again, sound familiar?

Plus, Ricigliano found that when he went in and talked about SOAP, UDDI, and WSDL, business end-users' eyes would glaze over -- even they were Sun Microsystems business end-users. "It's very hard to connect the dots for people and show them the real value of SOA," he said. "It was all very theoretical. We'd say, 'Hey we're decoupling these systems from each other. It'll be more flexible.' I don't know if they really got that. They could care less about the technology, unless they think it's going to get them something quicker."

Once again, sound familiar?

The way Ricigliano finally began to build support for Sun's SOA was by actually building business process demos, employing services such as credit checks. Showing tangible examples of SOA in Action got the ball rolling at Sun. "The end users get that entirely," he said.

Perhaps Sun and other vendors eating their own dogfood will be able to leverage some of this understanding to help their customers better sell the benefits of SOA within their organizations. When vendors themselves have issues selling SOA to their own business users, you know its no cakewalk at non-technical companies.

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

EbizQ colleague Brenda Michelson has just announced that the newly formed SOA Consortium is seeking enterprise architects to participate in an industry survey that seeks to help understand where EA is today, where it will be in the future, and what it would take to make the transition. That's a lot of good stuff we need to know more about.

Again, the survey can be found here.

Last week, I joined Dana Gardner's SOA BriefingsDirect podcast panel, which hosted special guest Richard Soley, chairman of Object Management Group, the moving force behind the SOA Consortium. Richard provided a lot of good insights into the philosophy and driving need behind the combined enterprise-vendor group, and how it will help move SOA forward in the months and years to come. I'll post details of the discussion when Dana makes it available over the next couple of weeks.

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

If you've ever felt overwhelmed by the plethora of standards, specs, and protocols that have been generated in the name of simplifying service delivery, don't feel alone. There's at least 60 or more of these out there, covering everything from security to event notification.

innoQ recently put together a poster and all-in-one list of the specs and their sponsors, available both in graphic "poster" form and as a text listing.

Everything you need to know about XML, SOAP, WSDL, UDDI, and all the WS-splat standards -- all on one page.

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

A new survey conducted by Forrester Consulting for Progress Software Corp. confirms what many IT professionals and managers in the trenches already suspected -- there's a lot of integration work going on out there, and much of it is still manual.

The survey found that 55% of respondents reported that they had undertaken four or more integration efforts over the past two years, and 48% predicted that the number of integration efforts will increase during the next two years.

However, the survey of 407 senior IT decision makers at companies with more than $250 million in annual revenues found that manual efforts -- sheer brute force -- remains the dominant approach for integration of data silos. For example, 87% of respondents rely on newly developed code to integrate data, while 80% still manually change schemas as required. According to the findings, while these percentages will slightly decrease over the next two years, manual processes will continue to trump automation.

The pain points. Among those who write code for each integration effort, 75%t reported increased maintenance costs due to application complexity and 71% suffered from increased cycle time to integrate new applications. Another 71% of respondents who rely on schema changes to support new applications said that one of their challenges is slow response to required application changes. Two-thirds (66%) reported problems with unforeseen breakage of other applications dependent on the same data.

Can SOA come soon enough for these beleaguered integration specialists? About 44% of enterprises use SOA today, the survey finds. A total of 59% say they plan to use SOA for integration efforts over the next two years.

From the looks of things in the survey, it's not too soon.

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

"Two SOA Projects That Can Pay for Themselves in Six Months"

Now, there's an eye-catching headline if I ever saw one. (Okay, it probably doesn't rank up there with "I Was Abducted by Space Aliens," but you know what I mean.)

Measuring -- let alone achieving -- ROI from SOA projects is an inexact science, and in most cases, the payback from SOA is likely to be long term, because SOA is a long-term journey that gradually begins to involve and deliver value one business unit at a time. (Dave Linthicum, however, has done a great job of showing us how to estimate that costs of an SOA project.)

Dave and other experts also point out that many small-scale, incremental SOA projects can deliver some "quick wins," which is important for building support and involvement for SOA across the enterprise.

In this article, IBM's Sandy Carter -- who also just published a new book called The New Language of Business: SOA & Web 2.0 (details here)-- cites two examples of these quick wins that can help build an SOA constituency, and perhaps even spring an executive evangelist or two:

A centralized delivery-date service. How many times have you been given the wrong date on an order you were expecting? One retailer was struggling with a fulfillment chain that comprised multiple systems - each of which could update the promised delivery date for an order. However, when someone changed a delivery date in one of the many fulfillment applications, the information wasn't consistently updated in the order-processing system. The result, naturally, was customer confusion, and mangled delivery schedules.

The solution was to implement a centralized delivery date service -- a SOAP over HTTP service managed by an ESB. Now, when a delivery date is changed, the fulfillment system sends a delivery-change notification to this event-driven service through ESB, and as a result, the order system database - and any other system that subscribes to this service - is immediately updated. The total effort to create two centralized services and build an ESB required four developers for four months, Carter said.

Charge dispute service. Have you ever disputed a credit card charge and wondered why it sometimes took months to resolve? Maybe SOA could speed things up. Carter cites the example of a financial services organization had a manual-intensive process for handling disputed charges from customers of its large retail partners. When a retail customer disputed a transaction, the financial services organization would manually print all transactions and send them through ground mail to the customer to identify which transactions were being challenged. The customer would then have to sign these papers and send them back through ground mail to the financial services organization, which would then package them and send selected documents to the retail institution. After this paperwork was received, the retail institution would decide whether the charge should be removed. This process could take up to 20 days to complete and typically cost the organizations involved between $400 and $700 per transaction.

Carter reports that the financial services organization deployed a service in front of its core transaction system that now enables retail partners to transmit dispute claims to the financial services organization on behalf of the partners' retail customers. To register a dispute, customers now simply log into the retail institution's Website and view a list of transactions that have posted to their account. Customers can then select the transactions they wish to dispute. The Website sends this request to the financial services organization's transaction-dispute service. The authentication that customers provide while logging on to the Web site enables the financial services organization to eliminate the need for paper documentation with a handwritten signature.

Carter reports that the transaction-dispute process now averages a total of three hours, reduced from 20 days, and costs only US $40 to $70 per transaction, instead of the previous $400-$700 per transaction, representing a 90 percent reduction in costs. "Automating this process by creating a centralized service helped enable the organization to realize estimated cost savings of more than $200 million per year," she says.

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

SOA success doesn't come all at once -- it's built incrementally, usually starting with some type of integration project. Kicking off last week's Skyway Webinar (hosted and archived here at ebizQ), Mike Gilpin of Forrester Research spoke at length about the common characteristics of the SOA projects he has seen succeeding at enterprise sites. I had the opportunity to moderate the session, in which Mike joined Jared Rodriguez, CTO of Skyway Software, for a discussion on how to succeed with SOA deployments.

Most SOA initiatives initially begin as integration projects, Mike pointed out. "One of the key ways that SOA tends to come into organizations is as a way to deal with integration problems," he explained. Such segways evolve out of "trying to work with a business partner through an interface today that would tend to be Web services-based; integration with back end systems, ERP. CRM, or other systems; or more focused toward front-end activities, such as content management or Web self service; or multi-channel integration of user experiences across Web, call center, email, devices, interactive voice response."

Typically, Mike added, "each of those individual technology areas tended to be addressed from an integration perspective in a different unique stovepiped way. You might have one Web-to-host approach that would be used to integrate a customer front-end application to a front-end, and a different approach used to integrate with partners."

SOA brings all these efforts together, he said. "With SOA, you start by building services in the middle, which are a representation of your business in digital form."

However, there are many ways to service-orient a system -- in fact, Forrester has identified a number of paths that can be followed, often in combination. First, there's "simple internal integration of a provider of a service with a consumer of a service without an intermediary" through a lightweight ESB, Mike said. The next step up is "rich.. internal integration through an intermediary that is providing transformation and guaranteed delivery, filtering, routing, and other kinds of value add. This may be more of the more functionally rich ESBs, which is also providing capabilities for semantic mapping and management features."

Model-driven development is another key positive attribute of successful SOA implementation projects, Mike pointed out. "Modeling not just in the old sense of pictures with boxes and lines, but modeling in the new sense of a model is metadata that defines the behavior of the application. Where that metadata is entered in development tools, perhaps through a visual representation, or perhaps through a form. That then survives into the runtime environment, and becomes part of the deployed application."

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

One might think a high-tech manufacturing operation would be light years ahead of your average business in terms of service orienting applications. But even the techiest of the high techiest firms are still run on behemoth ERP systems that tend to lock more data away than share it.

As SearchWebServices' Rich Seeley describes it, semiconductor testing manufacturer FormFactor Inc. "was
doing integration the old fashioned way, hand typing information from a legacy manufacturing execution system and then copying the data into the ERP system."

How quaint. A touch of life as it was back in the 20th century. Well, actually, there's still a lot of this manual process going on in the 21st as well. And that will be the subject of future blog posts.

The company didn't just decide to drop an SOA into the middle of this configuration. Rather, the company's IT director took a hard look at its business process management before seeing where SOA would fit. SOA would become the enabler for business process automation. "BPM and SOA go hand-in-hand," Nilay Banker, senior director of IT and business process engineering at FormFactor, is quoted as saying. "We are adopting an approach where we first start with BPM and then leverage SOA technology."

THe company relied on two systems -- a legacy manufacturing execution system originally built back in the 1970s, and a more recent Oracle E-Business ERP system. Data from the MES system had to be manually rekeyed into the Oracle system.

Banker's team went about the project by building Web services interfaces into the legacy MES system's operational data store. Data coming out of the MES system -- which tracks shop floor production issues -- can now be made available to decision makers on a real-time basis. No more waiting until the next day, after production data has been manually rekeyed into the Oracle system.

There's plenty of debate going on about the value of SOA, but what FormFactor is achieving after a few months' work -- eliminating manual rekeying -- is perhaps the most fundamental benefit SOA is delivering. Right away, there is documentable time being saved in clerical or operator salaries, as well as faster access to data. The "business agility" aspect that is promised by SOA may be difficult to grasp and measure, but here's an example of hard savings and highly tangible benefits.

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