SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
Building An SOA Pipeline
Service-oriented architecture may be a hot buzzword to some in IT right now, but when it comes to implementing a comprehensive IT-business strategy, buzzwords don't mean much. So why is
August 1, 2005
12 Min Read
Service-oriented architecture may be a hot buzzword to some in IT right now, but when it comes to implementing a comprehensive IT-business strategy, buzzwords don't mean much. That's especially true for a $45 billion multinational company such as British American Tobacco.
Why then are we embarking on this new technology architecture? In part, BAT's service-oriented architecture vision is based on our belief that simply adopting Web services standards isn't enough. We adopted SOA because it was time for an "industrial revolution." Our existing approaches to integration and application development were costly to implement and sustain, fragmented and hard to consolidate, and time-consuming and slow to deliver value.
In the past three years, as we researched the subject and made our purchase decisions, we found that SOA's true benefits begin to emerge only when a business shifts its IT orientation from a technology-architecture focus to a business-architecture focus. For us, this is a different way of thinking that ensures that new IT assets are built to be SOA-ready. We hope that a business-architecture focus will have long-term benefits, enabling different architectural layers to evolve independently and embrace composite applications. For the business, that means quicker solutions, lower costs, and greater agility.
To better understand the journey we've taken, some background is useful. British American Tobacco is the world's second-largest publicly traded tobacco group, with more than 300 brands in its portfolio. The group leads in more than 50 of the 180 markets where it does business, and employs more than 90,000 people.
We've gone with a traditional approach to integration and application development, and we've implemented a leading message-oriented middleware solution for integration and application-development tools, ranging from Java integrated development environments (IDEs) to Lotus Domino. This will all evolve into the new SOA architecture we're deploying across our global operating company.
As in all competitive industries, we need greater agility from IT so we can deliver innovative solutions to some business areas, while focusing on consolidation and the move to shared services in others. SOA is a great fit with these two conflicting objectives. One goal is to rapidly implement local-market initiatives at a much lower cost than previously possible. For example, we'd like to trim our overall application integration to roughly 40% of previous costs, while supporting a global ERP-consolidation program. We want to reduce approximately 65 ERP instances to eight by mid-2008. We also want to implement a number of global SAP and NetWeaver applications, including human resources, product life-cycle management, and supply-chain management. Our architectural vision for how SOA will shape our future IT is completely aligned with SAP's, and we plan to take advantage of its Enterprise Services Architecture strategy as soon as possible.
Even though we had the help of several partners, we were faced with confusion and misperceptions about what can and can't be accomplished with SOA. With the numerous advancements in service-based technologies and the rapid emergence of complex standards and tools, it's become extremely difficult for us, like others, to grasp what SOA is, let alone how it should be implemented. Many businesses are grappling with these same decisions.
To overcome this market uncertainty, we decided early to be very practical. We strive to eliminate the technical complexity of business-service creation and management, both inside and outside the enterprise.
Our IT department, led by CIO Phil Cook, supports this viewpoint wholeheartedly. By late 2002, we had developed an SOA direction; a year later, we had a well-defined vision. IT created that vision and is responsible for implementing the core SOA infrastructure and the supporting services. As a result, we have a global-service registry and the capabilities to manage those services throughout their life cycle. IT is also responsible for leading the adoption of SOA business solutions to deliver greater agility and business value.
Our global Enterprise Integration Community of Practice coordinates the global SOA initiative as well as local initiatives--such as taking an SOA-based approach to partner integration. The community comprises 15 to 20 leading architects from across BAT who work with my team to drive our strategy forward.
We developed our SOA plan after consulting with internal stakeholders, external analysts, and industry experts with a wide range of software and hardware knowledge. We set a plan to first select a technology platform on which we could build and extend existing and new business solutions. There were five key considerations: a relatively short time to develop applications; simplicity to learn; ease of managing, collaborating on, and deploying applications; support for Web services and SOA development; and compliance with an application-development tools strategy.
In November 2004, BAT signed with Blue Titan Software for its infrastructure software and Skyway Software for its SOA custom application-development software and application platform. We chose Skyway after one of our lead developers evaluated it and what had taken four days to create in Domino took just a day and a half in the Skyway SOA Platform--after a four-hour training class. This evaluation helped BAT confirm that implementing SOA wouldn't take months of retraining or specialized skills before we'd see results.
We're moving swiftly from pilot projects and exploration to real deployments. We have the infrastructure, tools, and resources in place; the first real services in production; and a number of projects in the pipeline for the remainder of 2005 and into 2006.
We believe this relatively modest investment will be returned many times. As part of the SOA initiative, migration from the IBM Lotus Domino platform to Java-based Rapid Application Development was a key objective, letting us move from a proprietary platform to 100% J2EE and SOA-ready applications.
The biggest technical challenges in the transition are skill-set migration and application conversion. Because the applications are deployed as J2EE, we've seen huge savings in time, productivity, and expenses. In fact, using Web services to integrate applications over the past two years has demonstrated savings of 60% to 70% over traditional hard-coded integration.
We've also recognized the need to factor SOA into our future architecture plans. By deploying this solution, we not only save money and improve productivity immediately, but we also get a head start on full enterprise adoption of SOA longer term.
Naturally, there were roadblocks, including version control, monitoring, maintenance, enhancements, and managing complex interdependencies found among different environments. We're also establishing appropriate processes and governance capabilities.
BAT can now ensure that all new development will be SOA-ready. This levels the playing field for BAT's developers--all will use the same toolset and develop in a service-oriented way. One of the misconceptions of moving to an SOA is that it's a huge challenge to work with existing assets, such as legacy applications, while leveraging developer skill sets and still maintain an acceptable level of developer productivity. Though we have no doubt about the value of SOA, reaping the largest return on investment depends on selecting the most flexible development platform. We're building a scalable platform so our developers can rapidly create SOA applications in well-formed J2EE code. We're confident that this will enable the loosely coupled business services that are needed in today's complex infrastructures.
As a result of our efforts, BAT developers now model rather than code, which lets them build highly decoupled services and processes at a much faster pace. This significantly reduces the high costs associated with retraining diverse skill sets, expert application integration, and technology assimilation.
BAT has successfully transitioned from SOA theory to practice, and our IT focus has shifted from technology to business. We believe that SOA should boost our agility throughout the software application-development cycle and that it will be a key strategy to cutting-edge industries like ours going forward.
Kevin Poulter is application technology manager at British American Tobacco.
Tell us about the pros and cons of SOA at [email protected].
See Related Articles:
Putting Application Integration To Work, November 2004
Services Take IT Back To Basics, June 2004
Now that BAT is well under way with its plans, six best practices for implementing a service-oriented architecture (SOA) are apparent:
Develop and maintain an architectural vision.
Don't assume you can build your SOA just by evolving the technology you already have.
Establish the infrastructure to make your SOA mission-critical early in the process.
Plan for new developments in the future.
Be prepared to move forward incrementally.
Get started sooner rather than later.
There are many ways to start a service-oriented architecture implementation.
If it's treated as a rapid-application-development project, the phases are clearly defined as follows:
Analysis
> Applications: Identify a small set of noncritical business scenarios to expose to services.
> Architecture: Create an infrastructure checklist--for example, application servers, EAI, portals--and address gaps.
Design
> Applications: Define service contracts (interfaces), scenario flows, and acceptance tests. Include service-level agreements (SLAs).
> Architecture: Define architecture services, such as messaging and data translation.
> Data: Identify data to convert; define data-conversion processes.
Build and test
> Applications: Create and unit-test business services.
> Architecture: Create, if necessary, and test architecture services. Note that these may already exist.
> Data: Formulate data-transformation processes.
System tests
> Integration: Test business scenarios.
> Performance: Test in a production environment against SLAs. Check stability, scalability, reliability, and response times, for example.
> Production readiness: Test business scenarios in a production environment.
Deployment and acceptance
> Data conversion: Populate data storage in accordance with transformation processes.
> Production: Roll out and run the acceptance test.
Service-oriented architectures are only one piece of an IT strategy to reduce costs while improving business performance. Most major software vendors are adopting a new concept called applistructure. Simply defined, it's the merger of enterprise-application and infrastructure technology.The promise is to shift time and money toward a strategic, next-generation infrastructure. AMR Research Inc. believes the ERP generation has run its course and the market is ripe for a new vision. A successful applistructure will accomplish five key tasks, each of which requires corresponding technologies and services:
1. Continuously cut the cost of IT: The hard lessons learned from slow economic growth should not be lost on IT groups. The most effective IT users tend to be the thriftiest. Rather than thinking that IT budgets must increase yearly--regardless of value or deliverable to the enterprise--companies should deliver a given value at ever-declining costs.
An applistructure provider must help its customers cut the cost of IT. Providers, in fact, help the market grow by eliminating wasteful spending in managing IT so the money can be transferred to margin-generating investments. To reduce the operational cost of technology, an applistructure must:
Support commodity hardware and software.
Enable open-standards support.
Manage applications and operational systems against practical metrics.
Deploy flexible licensing.
Offer on-demand, automated monitoring.
2. Deliver secure and reliable service levels: Because applistructure will become the key fabric linking and managing a company's business processes, it must deliver both security and high service levels. Unlike many technology trends--for example, client/server, object-oriented programming, and the Internet--reliability and scalability are top priorities for applistructure providers. Applistructure will require integration at both the process and data levels with customers and suppliers. It must deliver high availability, service-based management, and automated auditing.
3. Permit upgrades and product enhancements on the fly: One of IT's biggest challenges is to remain current with a wide array of products and technologies. This problem is particularly acute for large multinational corporations, which often have up to a dozen different versions of a single product installed globally.
This complexity makes upgrade and product-enhancement procedures for major application and infrastructure components akin to planning a space launch instead of a Sunday-afternoon drive with the family. Though best practices decrease complexity and problems, sellers have done little to make their products easier to install and upgrade. As a result, buyers are seeing little benefit to upgrading their technology and application portfolios. Many do so only under the threat of nonsupport.
Besides cost and labor issues is the need for business flexibility. Many companies are unable to proceed with their business plans because of the time and cost needed for technology upgrades.The current state of upgrades and installations inhibits business change.
To change the status quo, vendors must deliver rational, regular upgrade cycles; multistrategy releases; segmented, modular releases and upgrades; and installation and upgrade automation.
4. Let different technology providers plug and play seamlessly: The technology industry has touted the idea of universal technology integration for decades. Unfortunately, regardless of the approach--single vendor, objects, or enterprise-application integration--the goal has been elusive. The lack of universality has created a morass of integration techniques, resulting in excessive cost and inflexibility. To rid IT of this problem, a new and different approach is needed; one that's half technology and half definition.Existing Internet protocols aid simple communications and network-transport services, but they've created a false sense of security about the complexity that lies ahead for plug-and-play technology. The issue that technologists tend to ignore is semantics, which define the business language and relationships between companies. This isn't a trivial concept that will be solved quickly, though there's greater focus than ever on defining key business processes and elements. For plug-and-play integration, an applistructure must deliver semantic and services definitions, services management, an integration bus, and automatic configuration capabilities.
5. Permit a fast reconfiguration of business processes: Though IT has facilitated automation and efficiency in certain business processes, it hasn't addressed the rapid change of processes after they're automated. The technology trends and improvements of the past 15 years--including client/server, object technology, industry standards, and the Internet--haven't changed the fundamental inflexibility within most applications. New technologies and approaches are needed to permit reconfiguration. One promising approach is composite applications. SOAs, graphical, model-based programming, business-process implementation tools, and the ability to span multiple products and processes are needed.
CIOs face many decisions regarding applistructure. One way to smooth the transition is to develop an applistructure-investment map. Knowing that applistructure will develop in the next three to five years, technology buyers should look at their long-range IT plans and identify areas of potential investment and overlap in their current technology landscape. For the two dozen components of applistructure, an applistructure map would identify the providers of each technology and indicate how a company's IT projects and technology-capital expenditures will align with the delivery schedule of applistructure. The goal is to quarantine technology providers that would no longer be necessary because of overlap with the offerings of a major applistructure provider.
Buyers have a tough road ahead. For now, they need to educate themselves and make long-range plans. The burden is on the seller community to prove that applistructure can be made practical.
Eric Austvold is research director at AMR Research Inc.
You May Also Like
More Insights
