While the promised benefits of a service-oriented architecture are becoming increasingly clear, converting legacy systems over to SOA continues to pose challenges.
We asked a number of industry leaders what their views are of the future directions of service-oriented architecture, or SOA, and received back a number of interesting responses. The large amount of stable code in place today that doesn't really lend itself well to a service-oriented architecture makes true conversion difficult. Programmers and IT administrators nevertheless are working to implement services, and SOA, one step at a time where it makes sense.
Creating business mashups is a way of giving users a similar experience to that of SOA without reengineering legacy applications, and many shops are also introducing Web services. On the horizon, however, are automation tool suites that will be able to convert legacy applications to true SOA on a large scale.
Following are comments of five industry leaders who were generous enough to take the time to write down their thoughts on the future of SOA and the challenges it poses for IT and today's businesses. For further information, you may wish to consider reading SOA for the Business Developer by Ben Margolis with Joseph Sharpe available from the MC Press Bookstore.
Duncan Kenzie
President and CTO
BCD Product Development
I believe SOA will increase in strategic value in the next couple of years as more enterprises look to ways to easily share information between disparate operating systems and databases. SOA provides a loosely coupled solution for aggregating data and delivering it in a single, common user interface, especially with Web applications.
For example, our portal product Nexus and Web development tool WebSmart work well together to allow developers to easily fetch information from different servers via AJAX and simple Web server calls and to integrate that data in portlets.
One of the challenges of SOA, though, is having a consistent API to communicate between servers. One approach to solving this challenge is to use clearly defined XML schema, but XML can be challenging for humans to read and, therefore, debug. It is also not particularly lightweight, so if you are transmitting large amounts of data over the network, you may experience performance issues. A more recent approach that has gained considerable traction in the last year is to use JavaScript Object Notation, or JSON. JSON has the advantages of being both lightweight and easier to read. It also works well with client-side, AJAX-driven applications that rely heavily on JavaScript.
In summary, as Web applications increase in richness, responsiveness, and complexity and as business needs for more readily integrated data increase, SOA will play a larger strategic role in software development activities.
Eden Watt
Vice President of Professional Services
The explosion of the Internet has transformed our planet, how we communicate and collaborate with the world both personally and professionally, and how we must manage and evolve IT assets, which are critical to the success or failure of our businesses. SOA, as a discipline, is key to how we do this. Implementing SOA means working toward modularized, composite applications where discrete business functions or tasks are available as services, both internally and externally.
The challenge for many organizations is how to move forward with this transformation while leveraging existing IT assets and without significant disruption to current business processes. A full-scale overhaul of an organization's applications and business model, in order to implement SOA, is often not practical. With LANSA, we typically work with our customers on a staged approach which aligns business goals with IT and, of course, with the budgetary and time constraints of the organization. This can involve a mix of application modifications, technology solutions, and strategic services offerings. Sometimes, the focus is one particular business process, workflow, or innovation at a time.
The opportunities to take advantage of evolving capabilities in areas such as cloud computing and mobile applications to implement new and improved business processes and operational efficiencies will necessitate this move toward SOA-enabled enterprise applications.
Stuart Milligan
Director
Over the last decade, most of our customers and the companies we talk to have a desire to implement some form of SOA architecture over their legacy applications. The monolithic, single-entry-point nature of most legacy systems has largely inhibited any significant progress for most of these companies. The first stage in any legacy-to-SOA transformation is analysis—analysis of business logic and reusable design constructs. Our tools have made the extraction, indexing, and analysis of business rules in legacy RPG/COBOL/CA 2E fully automated, and, in the process, have saved some companies many years and millions of dollars worth of manual efforts. Even so, the actual transformation of the legacy code to SOA still remains a complex and difficult process and, up until now, has largely been done manually.
In parallel to our analysis and extraction engines, we have been evolving our reengineering technologies to create distributed, or MVC [Model-View-Controller], architecture from monolithic, interactive legacy code. Variants of this with ever-increasing levels of automation have been available since IBM wrote the Redbook on X-Analysis in 2005. As a conscious design choice, we now implement the reengineered code as a series of Web services, thus achieving long-term modernization and SOA simultaneously.
To put the complexity of this task into perspective, note that we started the reengineering tool project in 1999. It's now 12 years later, and we have just completed it for CA 2E applications to the point where any user can use the tool to reengineer CA 2E systems to SOA and/or MVC. The RPG to SOA and/or MVC is still about six months to a year away before it will be ready for widespread deployment by someone with an RPG system that expects a very high level of automation. Can you imagine—13 years to develop a tool! It should give readers some indication of how difficult the task is of moving legacy applications to SOA. Without automation tools, it is unlikely that many companies will realize cost-effective SOA implementations on any large scale within the next five to 10 years.
Ron Nunan
Product Marketing Manager
Today's IT teams are driven to be reactive to needs of the business, and teams are constantly looking for solutions and strategies to keep up. We are seeing that a services approach to IT projects is truly becoming the preferred method for building solutions, not just in rhetoric, but in practice. This approach has clear benefits, including better flexibility, which allows IT to be more responsive to the business.
That being said, we should acknowledge that a services approach is not the same as service- oriented architecture [SOA], which uses and depends on services. SOA extends to service use, policy control, life-cycle management, and other aspects of maintaining healthy and best-practice use. While a full SOA architecture can be a well-thought-out strategy, it isn't easy to sell to the business because it isn't always clear to the business how a full SOA, at a big expense, helps IT meet its ever-changing needs, rapid time frames, and constrained budgets.
So while a full SOA is a worthy goal for any organization, the simple use of a services approach within a project can be an easier entry point and allows organizations to do more with less. We at Attachmate see this scenario often with our customers leveraging our Verastream legacy modernization solution; building services out of legacy applications is enough and can provide important benefits all by themselves. And there is always the belief that incorporating an SOA infrastructure over time will increase the benefits even further.
The future of SOA will be the growing use of services to meet business needs—from new applications to legacy modernization projects. This shift will create a semi-managed services infrastructure but will leave many aspects left to complete at a future date. Because of this, we can expect to see a growing set of tools and infrastructure to help businesses deliver on the SOA promise. Expect to see all IT shops continuously increase their goals for SOA as their service inventory grows. The benefits of using a services approach improves when the services are surrounded by a more robust and tailored services architecture. Through the increased use of ad hoc tools and management infrastructure, we believe IT will learn to better balance, staying within the constraints of the business while fulfilling on the promises of a full SOA.
Eamon Musallam
Product Manager
SOA can provide so many benefits to development teams. From an IBM i perspective, adopting an SOA approach to modernization and ongoing development enables the IT team to be much more responsive and agile to the ongoing demands of the business environment it supports. Probably the biggest benefit is being able to adopt the latest technologies like mobile device support, Web deployment, and cloud computing. Ongoing maintenance of the application becomes easier because of a stronger emphasis on reuse and a modular approach when developing.
looksoftware has found that the biggest challenge is the difficulty that often faces those teams who are maintaining purchased packages where they do not have the ability to transform those applications, or the extensive effort required if they are dealing with older applications (say 20 years old or more) with a significant amount of legacy code. However, those customers that do move to SOA most often find that the benefits outweigh the effort involved. For a quick read of iSeries issues pertaining to SOA, see the looksoftware document, "All You Need to Know About Service-Oriented Architecture (SOA) and System i."
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1
LATEST COMMENTS
MC Press Online