Service-oriented architecture (SOA) projects tend to be large initiatives with lots of risk and potential reward associated with them. The ROI is very hard to quantify and thus hard to sell. A solid process and methodology are required to ensure success of the project.
SOA is a set of tools, technologies, frameworks, and best practices that enables the quick and easy implementation of service. In addition, the process of developing SOA uses methodology for identifying reusable services in our applications and organization.
Gartner Group predicts that 20% of Fortune 1000 companies will deploy an Enterprise Information Management (EIM) strategy in support of SOA. Gartner also estimates that SOA will provide the basis for 80% of new development projects. SOA is also expected to enable organizations to increase code reuse by over 100% by 2008, saving developers time and energy.
SOA will be the guiding principle when creating mission-critical applications and processes. Businesses that ignore the potential of SOA will find themselves outpaced by rivals that improve their agility and transform themselves into new kinds of enterprises. By 2010, at least 65% of large organizations will have more than 30% of their application portfolio SOA-based, which is up from fewer than 5% of organizations in 2005.
SOA is targeted at reducing the complexities involved in software development. It addresses issues with multiple platforms, distributed software, and application integration. It provides an application architecture in which we define processes as services that have well-defined interfaces. The services can be dynamically invoked within the network. SOA enables faster delivery of business processes as well as cost decreases resulting from reductions in development and maintenance cost.
The Problem of SOA Complexity
IT complexity remains a huge burden for most enterprises. SOA promises to enable business agility, but, according to Gartner, "Out of control IT complexity often turns these systems into the key obstacle to business agility instead." ("Applied SOA: Conquering IT Complexity Through Software Architecture"—ID# G00128127).
A number of factors have led to this complexity:
- The history of enterprise architecture can be seen as disjointed legacy evolution. Most enterprises grafted new functionalities onto what they already had, resulting in a heterogeneous environment made up of both legacy applications and newer, service-based technologies. Systems were developed without consideration of any future need for information sharing, integration, or code reuse.
- Shifting architecture paradigms continue to introduce complexity. For example, when outages occurred in the old client/server architecture, we could easily pinpoint a failure, and possible sources were limited to a handful of systems. In a service-enabled composite environment, the application server is a central point of coordination across multiple client/server systems, and a failure can occur anywhere along the transaction path.
- Business factors such as a change in organizational structure, additional business functions, or mergers and acquisitions can also increase complexity of enterprise architecture. Associates that previously were experts in specific areas of enterprise responsibility can find themselves working in new departments, leaving behind knowledge gaps. As a result, additional application functionality tends to be "glued on," making the service more complex.
- The ability to rapidly deploy new business functions, or versions, makes it difficult to accurately map out the application architecture. IT organizations are continually expected to achieve more with less. Almost as soon as everything is mapped, the chart becomes out-of-date. In this example of a rapidly evolving environment, how can someone troubleshooting a single transaction know which service was deployed at the time of error?
- Good old-fashioned internal politics often leads to business decisions made without technological or architectural consideration. "Vendor self-preservation" results in technologies designed to help vendors, not necessarily users.
SOA promises to allow one system to interoperate seamlessly with another. Traditionally, information systems operated independently, managing their own data, and remained blissfully unaware of other systems within the organization. The advent of Web-based technology and the requirement to share data between disparate sources led to the creation of point-to-point communication between applications. SOA replaces hard-coded links with a loosely coupled approach. Consequently, businesses must pay more attention to the integration point.
Developers of one service typically don't know much about another service, other than the information provided—for example, from the Web Services Description Language (WSDL). Therefore, they have no means of diagnosing problems caused by a service, and they may not be able to identify which service caused the issue. This lack of visibility is one of the biggest challenges with SOA implementation. An effective service management solution is important in the design of an SOA enterprise.
Managing performance also becomes challenging when a particular component or service is shared among several applications. Various applications have different load requirements. New applications can be deployed anytime, and the service administrator may not be alerted regarding the increase in usage. The varying application usages make it hard to plan for and predict service load stresses.
As SOA becomes the standard for all application environments, the difficulty of managing them and the need for transaction visibility grows exponentially. The very fact that SOA makes it easier to integrate Java and legacy systems means that management tools must be able to reach across and within all of our systems to discover relationships and dependencies.
The 5 Stages of SOA Maturity
A successful SOA project will go through a series of stages to reach satisfactory completion.
Stage 1: Initial Services
This is the current state of most organizations. There is no separation of architecture from projects. Typical projects are designed in silos by the project leader, with the help of line of business (LOB). Success in the organization depends on the competence and heroics of people in the organization, not on the use of proven processes. In spite of its challenges, this stage often produces products and services that work. However, this method frequently exceeds budget, increases the cost of delivery, and results in an unpredictable project schedule. Code is typically not reusable and is hard to maintain.
Stage 2: Repeatable/Architected Services
Stage 2 represents the early "initial learning" phase of SOA adoption. It includes R&D activities and testing of SOA technologies in "sandbox" environments.
The organization moves toward some form of Enterprise Application Integration (EAI). Projects are done to meet the specific need to "implement functionality" while trying out technologies recommended by the enterprise architect. The element of enterprise architecture emerges. Enterprise architects help put structure in place and foster communication between teams.
Project teams define reusable architecture that they use from one project to another. The organization componentizes or modularizes major or critical parts of the application portfolio. The result is some level of reuse of architectural components. The benefits of reusable processes are recognized. Software development and deployment are properly scheduled, and improved overall quality of the software results.
The key business benefit of this stage is development and deployment cost-reduction through the use of the SOA standard infrastructure and components (as opposed to using older technologies and accumulating cost through multiple unique, one-time projects). Services are consumed internally, not quite on a large scale, but the system acts as a service provider nonetheless.
Stage 3: Collaborative/Composite Services
The focus of this stage is the partnership between business organizations, information technology, and enterprise architects in order to ensure that the use of SOA provides clear business responsiveness. It focuses on the implementation of internal and external business processes.
The standards, process descriptions, technology policies, and procedures for a project are tailored to suit a particular project or organizational unit. Therefore, they are more consistent. At the end of the day, IT recognizes that they are serving the business.
Stage 4: Managed/Measured Services
At this stage, enterprise architects start defining a path to SOA. Quantitative objectives are established and used as criteria in managing processes. These quantitative objectives are based on the needs of the customer, end user, organization, and process implementers.
An organization can be classified as being at this stage only if its SOA initiatives seek buy-in from business. Governance and rewards policies should be defined. Support levels need to be established, with clear understanding of whom to call, when, and for what.
A framework for analysts to define services must be established. How does LOB identify potential services that it can expose? Who is responsible for building and maintaining this service? Who pays for it? These are some of the questions the SOA plan should answer at this stage.
Stage 5: Optimized Service
At this stage, the organization continually improves its processes based on the quantitative measurements from the previous stage. It focuses on constantly improving processes and performance through incremental and technological improvement.
A framework is in place for each team to consume and expose services. At this level, organizations truly explore the meaning of SOA. They start to figure out how to exchange services with business partners, suppliers, and customers. Business service level reuse, not just technology component reuse, is the key to achieving maximum agility.
A critical distinction between stages 4 and 5 is the type of process addressed by business. At stage 4, the organization is concerned with addressing the cause of the process and the predictability of the result. At stage 5, the organization is concerned with the common cause of the process; it will change the process to shift performance and to achieve the quantitative objective that meets or exceeds expectation.
Incremental Adoption of SOA
The stages mentioned above often overlap. The process of adopting SOA starts at stage 1 (Initial Services) and then gradually evolves to a technology adoption within a group that is engaging in the SOA style of projects, using tools, technologies, and methodologies that enable the creation of proofs of concept (POC). Assessments can be done during adoption. The functionality of the proposed services needs to be evaluated, validated, and verified by enterprise architects.
Once the technology adoption stage starts to achieve maturity, the results start to trickle into the LOB, which sees the value in sharing services across lines of business to eliminate redundancy and in having a single point of access to existing functionality. This always reduces cost and complexity and adds to increased flexibility.
Business starts using services to access common functionality, often starting at a technology level and then moving on to the business level (which provides greater value). Businesses can begin to partition business functions to eliminate redundancy. This requires a certain degree of business buy-in as the project evolves toward consolidation of business function across lines of business.
At an enterprise level, standards and governance are adopted. Adoption includes protocols, tools, standards, and service models. These are extended across the organization.
It is at the higher stages (managed and optimized) where changes could ripple through other service consumers and producers. For example, a change in the business process could impact multiple components, such as the management of services that coordinates the interaction between multiple services. Or the contract of services could be impacted because of a change in the relationship mapped within the architecture. So how do we define "business rules" within SOA? Do we view them as a componentized process in relation to the architecture? Or do we have a different perspective of the business process within the context of SOA?
Realistic System i SOA Implementation
The maturity model I provided earlier is a collaborative effort pioneered by SOA vendors. Each of the stages provides a set of technologies and articulated business benefits. The stages provide milestones to help build an SOA roadmap for your System i. However, the model itself is agnostic in some ways and may not be suitable to all System i environments. There is a danger here: If potential SOA adopters focus too much on technology maturity, they could be focusing on the wrong thing.
Alex Nubla works as the Enterprise Architect for Health Net. He used to write technical articles for Powerbuilder magazine, Midrange Computing magazine, and iSeries News magazine (even way back in News 3/x days). Alex lives in Southern California now, after relocating from Charlotte, North Carolina, where he worked for Bank of America as the V.P. in charge of technical support for System i.
Alex hasn't written articles for the past nine years because of the high demand on his consulting work. However, he has written numerous utilities and always makes them available for free in the System i community.
Alex has always been a great supporter of the System i. He has butted heads with other industry folks who refer to the System i as old technology. He says, "I don't want to be portrayed as an old bigot who loves System i, but the truth is System i is here to stay. And please, don't call it a legacy system."
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online