Are You Really Ready for SOA?

Are You Really Ready for service-oriented architecture SOA? By Charlie Feld

June 29, 2007 — CIO — Most major organizations claim to have a service-oriented architecture (SOA) plan. Not to have one would be oldfashioned. However, successful implementation of end-to-end data and business processes integration requires not only a technology architecture but also a parallel business architecture. You simply can't have a modern business model without modern processes, software and infrastructure that are tightly integrated.

But in most enterprises, this integration between IT architecture and the business model remains poorly articulated. I call this the CEO/CIO dialogue gap. This gap exists to some extent because of the relative "newness" of IT as a discipline. Professions like finance and manufacturing have matured over hundreds of years, with principles, structures and a body of knowledge that are well understood by business leaders. However, IT has been part of the commercial landscape for only four decades.

During the last 10 years, some CEOs and CIOs have been able to close the dialogue gap. However, in today's flatter—even upside down—world, competition is much harder and business moves much faster. In such exhilarating and dangerous times, strong leadership really matters. There's no longer any room for miscommunication between the business and IT.

More from Charlie Feld Total Leadership: How to Build a Great Team

Must-Have CIO Skills: Innovation, Business-Savvy

Change Management: Leading Through Technology Changes Critical Alignment
The struggle for business/IT alignment is decades old. But today, the stakes are much higher because technology is becoming fully integrated into every facet of customer, supplier and employee interactions. The challenge for CIOs is multifaceted. First, they must grasp the competitive business context of their enterprise and understand the durable processes that drive the business versus organization structures that are perishable. Then they must be able to build a realistic multiyear modernization plan for the enterprise and establish process, data and investment governance structures with the executive team. Finally, CIOs must be able to articulate the value of the above to their business constituents continuously and with passion.

This is a tall order, but it's critical for the success of a modern enterprise. In the past, we could get away with short-term commitments and much less discipline because we were funding and executing projects that were contained within a business function and limited to a specific technology. But in our current era, most business processes require real-time integration of data and applications. If the business and IT integration model and investment strategy are not well-understood, aligned and managed over multiple years, you could end up with poor business results, dissatisfied customers and out-of-control IT expenses.

Source: http://www.cio.com

How will SOA affect my IT group?

How will SOA affect my IT group?

If you have a decentralized company, be prepared for a struggle. Service Oriented Architecture SOA drives centralization. Indeed, it demands it. "You have to have someone heading it up, and you have to have one individual or small team manage the architecture," says Mike Falls, senior system engineer for Fastenal, an industrial and construction supply company. "If each team is left to itself, they may each come up with different ways of building services. You need one group, one set of research and someone to make sure the development groups are sticking to the service development methodology."

As the service portfolio grows, the development process may begin to look like an assembly line. "It becomes a factory," says AEP’s Wissner. "You have these different project teams that you funnel work through, and they can grow and shrink as required."

Once the Service Oriented Architecture SOA factory gets ramped up, expect to add more project managers, business analysts and architects as the productivity of the developers increases, says ProFlowers’ Hall. "Two developers can now do the work of six," he says. "That means the architects and project managers are running to keep up with the output of the engineers. We are probably doing 50 percent more work than we did three years ago."

Those programmers need to understand object-oriented programming and distributed applications—and that means an investment in training. According to the CIO/Computerworld survey, only 25 percent of respondents have the staffs they need for Service Oriented Architecture SOA—49 percent said they are planning or have training programs in place for current staff to bring them up to speed.

Source: http://www.cio.com

How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?

How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?

Architectural planning is time-consuming. Service-oriented development, drawing upon well-known programming principles and widely available technology standards (such as SOAP, HTTP and so on), can happen a lot faster. But the two need to happen in parallel, say experts. "We do development projects as needed, and then on the side we have a longer multiyear project of mapping out the processes and building enterprise-level services," says Kurt Wissner, managing director of enterprise architecture and development for American Electric Power (AEP). "People need to see the benefit of SOA pretty quickly. That’s why I like the project route, because otherwise you don’t have anything tangible to sell to anyone about why you’re doing this."

While it would help to have the architectural plan and the process mapping in place before building the services (to improve the chances for reuse), architecture planning has no short-term payback, which can be devastating. "I tried to boil the ocean at another company and I failed," recalls Wissner. "We did a big multimillion-dollar architecture plan that duplicated what we already had. It didn’t provide much value over traditional point-to-point integration, and we had nothing to show for our efforts. If you start with the entire enterprise, there are too many risks you might fail."

By taking the enterprise planning in smaller chunks at AEP, Wissner can more easily recover from setbacks. "We’ve had hiccups but could take corrective action because the issue wasn’t that big," he says. "If you break it into simpler pieces, it’s more easily digestible."

Successfully Planning for SOA - Part 1

Successfully Planning for SOA : Taking a strategic approach to realizing SOA (Part 1) by David Groves

As you continue to develop your IT architecture, it becomes clear that the route to achieving real business benefits requires a fundamental change in the way you think about system design. In this article on services-oriented architecture (SOA), I'll share with you helpful tips, insights, and a domain model to help you plan this change, and ensure the success of your SOA implementation.

SOA: A New Way of Thinking

Albert Einstein once said, "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." In today's enterprise computing, this suggests that the challenges IT faces in delivering successfully to the business cannot be overcome without changing the way we think about IT. For developers and enterprise architects alike, services-oriented architecture SOA provides a structure for that change. The question then becomes: How do we migrate to that new level? How do we prepare for such a fundamental change? How do we do so in the most cost-effective, least organizationally traumatic way possible? The answers begin with proper planning.

SOA services-oriented architecture is not so much a technology as it is a way of thinking. It is bold agenda for infrastructure reformation and represents a culture shift in how we employ technology and work together. Its sudden popularity is less a product of hype than it is recognition of SOA services-oriented architecture as an evolution towards providing closer alignment between our business and our IT systems. Also, that evolution is stunning and far reaching in its implications for the success of our enterprise.

What Is SOA, Really?

Service-oriented architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs.

A service is a module of code, governed by a service level agreement, which can be accessed via a standards-based interface. Each service represents a piece of functionality that maps explicitly to a step in a business process. Services can either be written from scratch or mined by exposing modules of existing system functionality from previously "silo-ed" applications.

Over time, a catalog of services can be built up, allowing business functionality to be fluidly accessed and reused across many different systems. In this way, SOA services-oriented architecture can eliminate duplicate data, rekeying of information, and human error at the tactical level while enabling strategic change - for example, by creating a single view of the customer, and in the process opening up new possibilities for cross-sell, up-sell, and offering services for a more attractive user experience.

New Infrastructure Paradigm

Part of the paradigm shift of SOA is a move from application infrastructure to service infrastructure. Prior to SOA services-oriented architecture, applications were organized into "silos" with point-to-point connections. SOA uses the same back-end application engines and middleware, but leverages a converged Service Infrastructure Layer (Figure 1).

Implementing SOA

As you begin to implement SOA, use the following formula:

• Think Strategically, Execute Tactically: Start by realizing a single-core process with simple, agnostic services that span multiple business units
• Top-down: Identify the services required to support this single-core process
• Bottom up: Identify functions in existing systems that could be exposed as services to support this process
• Infrastructure Services: Identify common supporting functionality requirements
• Expand Slowly: Technically challenging projects may be undertaken concurrently after initial projects have proven successful
• Build an Application Catalog: On a project-by-project basis, harvest and reuse service modules, thereby reducing your cost curve over time
• Focus on Benefits: Phase projects in order of ROI, in stages that include plateaus for consolidation

Using the BEA Domain Model To Plan Effectively

• To be successful, SOA requires IT and the business to work together in new ways. As you plan for services-oriented architecture SOA, you will need to create an effective balance between the technical and nontechnical elements. To this end, BEA has developed a domain model (Figure 2) to help guide you through planning the six key areas that must be given equal consideration to ensure a successful implementation. The first three (Business Strategy and Process, Architecture, and Cost and Benefits) are a good place to begin the planning process.
• Business Strategy and Process: Mapping services-oriented architecture SOA to Your Business

SOA maps IT functions to your business processes, thereby enabling business improvement over time. This mapping process is best expressed as follows:

Analyze: Study processes and identify the supporting functionality required
Develop: Harvest functionality from existing IT assets, develop new functionality, and ensure that all services have clear service-level agreements.
Utilize: Orchestrate services into processes, measure alignment with strategy, and identify opportunities for optimization

Architecture: Defining Long-term Needs
Establish a reference architecture for your IT organization. This is not a current state diagram, but a long-term vision to build against, which should incorporate a two-to-three year architectural vision of where your business is heading. Take the time to define your architecture's guiding principles and policies, but be wary of making those guidelines an end unto themselves. The flexibility and modularity of the services-oriented architecture SOA system should take first priority.

Cost and Benefits: Demonstrating Immediate Business Value
SOA is designed to hit the ground running, and it is important to prioritize the development of services in a cost-benefit order, so that your services-oriented architecture SOA shows ROI from the start. With careful planning, "start-up" costs can largely be absorbed into existing budgets. Over time, the reuse of service modules ensures a lower start-up cost for each new business application. Ensure measurability by setting your baseline at the beginning of your implementation, and avoid the need for backfilling down the road.

Using the SOA Maturity Model
BEA's SOA Maturity Matrix will help you to monitor your services-oriented architecture SOA rollout, thus helping you to monitor your progress against the different phases of development. This matrix is divided into three stages: exploring, expanding, and Exploiting. To assess your architecture's maturity level, you may use BEA's Online Self-Assessment Tool (www.bea.com/soa).

Conclusion
It has been my goal in this article to offer you some pointers for organizing successful services-oriented architecture SOA planning, and my belief is that in taking this approach you can achieve the smoothest SOA rollout possible, and move your organization on to the next level of your development and business agility. For more information on BEA's SOA solutions, please visit www.bea.com.

Source: http://soa.sys-con.com

Successfully Planning For SOA, Building Your SOA Roadmap - Part2

Successfully Planning For service-oriented architecture SOA, Building Your SOA Roadmap (Part 2) by Stephen Bennett

In this second article about service-oriented architecture (SOA), I offer a concrete plan, along with tips and insights, to help you build an effective SOA roadmap, and to help ensure the success of your service-oriented architecture SOA initiative.

Any great journey starts with a goal or destination, and your organization's decision to implement service-oriented architecture SOA is no different. However not unlike the pioneers who set off west in their wagons, you may start with only a vague idea of what awaits you, or how you might get to your destination. To be successful, you must assess your strengths and weaknesses, establish clear direction, choose a route, and then consistently reassess that route as you follow it. You must, to put it simply, create your own unique map for your journey.

What Is an SOA Roadmap and Why Do You Need One?

Service-oriented architecture SOA is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs. The benefits of SOA will only be realized if the balance between long-term goals and the shorter-term needs of the business are preserved. This balance can be maintained by instituting a set of organizational, financial, operational, design, and delivery practices from the outset of your SOA initiative. However it is important that these culture-changing disciplines are deployed in an incremental and iterative fashion, rather then a "big bang" approach, which allows for an organizational learning curve. In essence, an SOA roadmap is an iterative and incremental way to capture (and recapture) your organization's unique plan as you progress.

Your SOA Roadmap should contain three critical characteristics:

Maturity: Treat your service-oriented architecture SOA Roadmap as a "living document" that continually captures experiences and lessons learned. As your SOA roadmap matures, your SOA initiative reaches higher levels of sophistication, in a controlled manner. The creation of an SOA roadmap begins with an assessment of your organization's current capabilities and disciplines that are applicable to service-oriented architecture SOA. This process can be initiated by using BEA's Online Self-Assessment Tool (www.bea.com/framework.jsp?CNT=index.htm&FP=/content/solutions/soa/).

Scope: A complete SOA roadmap should encompass all six domains (see Figure 1). These domains, while distinct, are interrelated and interdependent. Executing on each domain is fundamental to the success of an enterprise-wide SOA initiative. The service-oriented architecture SOA roadmap should clearly delineate the boundaries of your SOA initiative and establish a transparent and flexible timeline for achieving SOA goals. These goals should be broken down into manageable phases, which can then be realized in an iterative and incremental manner.

Quality: By applying a "Learn and Adapt" process at each milestone, and by being both iterative and incremental, your roadmap will remain relevant throughout the service-oriented architecture SOA initiative. To ensure your SOA roadmap's quality, communicate and validate it with all stakeholders, soliciting feedback and buy-in from all quarters.

How to Build an SOA Roadmap

There are four phases to developing your service-oriented architecture SOA roadmap: SOA planning, SOA maturity assessment, SOA future vision, and SOA roadmap definition.

SOA Planning
During this phase, your service-oriented architecture SOA initiative is organized and defined. Stakeholders are brought into the process through communications and briefings, and mutually agreed upon priorities and parameters are set. Because this phase involves employees across your organization, clear and ample communication is critical. During this phase you will:

Define the scope of SOA service-oriented architecture
Establish boundaries and alignments with other IT initiatives
Appropriately showcase the business justification for SOA
Show alignment of existing and future business initiatives

SOA Maturity Assessment

During the service-oriented architecture SOA maturity assessment phase, you will establish a metric for where you are today. Here you will define what services and capabilities you currently have that can serve as a starting point for SOA, as well as identify projects that might serve as foundation projects. Through a series of interviews and questionnaires, your teams should examine the various domains - analyzing, base-lining, and validating the "as-is" current situation for each. Use of BEA's domain model allows you to structure your examination of the following:
Business Strategy and Process: A top-down view of business strategies and processes
Architecture: A review of current architectures, policies, and standards
Cost and Benefits: Overview of existing cost structures and benefits cases
Building Blocks: An analysis of existing services, processes, tools, and technologies
Projects and Applications: Review of existing systems and in-flight and planned projects
Organization and Governance: Analysis of existing governance structures and policies

SOA Future Vision

In this phase, teams use workshops to determine and define the future desired "should-be" state and ensure cross-organizational buy-in:
Business Strategy and Process: Correlation of service-oriented architecture SOA future vision with business strategies and processes
Architecture: Architecture guiding principles, requirements, policies, standards, and reference architecture
Cost and Benefits: Metrics and measurement requirements
Building Blocks: Shared services infrastructure requirements, standardize tools
Projects and Applications: SOA mapping to projects and applications
Organization and Governance: Governance and compliance structures and policies

SOA Roadmap Definition

This phase is where the service-oriented architecture SOA roadmap is initially defined. A complete gap analysis should be performed for your corporation's SOA goals and appropriate timelines, based on the information gathered in the previous three phases. Near-term events will be more detailed, while later events will be more fluid - so that they might incorporate lessons learned as you move forward.
Business Strategy and Process: Opportunity alignment by business value
Architecture: Near-, medium-, and long-term reference architecture roadmap
Cost and Benefits: Roadmap of future metrics, cost structures, and benefits cases
Building Blocks: Prioritization of shared services strategy and standardized processes
Projects and Applications: Project and application impact
Organization and Governance: Proposed governance structures and policies
Your service-oriented architecture SOA roadmap should be treated as a "living document" that continually captures experiences and lessons learned. As your roadmap matures, your SOA initiative will reach higher levels of sophistication in a controlled manner (see Figure 2).

Conclusion
The goal of this article is to provide you with a framework for creating your own SOA roadmap, and an explanation of why that roadmap is so important for your service-oriented architecture SOA initiative. Your roadmap is your guide for what to develop, when to develop, and when to deploy what you've developed, and should be your single most powerful tool for a smooth deployment of service-oriented architecture SOA. For more information on BEA's SOA solutions, please visit www.bea.com/soa.

References
BEA Domain Model Whitepaper (PDF): http://contact2.bea.com/bea/www/soarc/ login.jsp?PGM=1&PC=10SOSO4
Successfully Planning for SOA: http://contact2.bea.com/bea/www/soarc/ login.jsp?PGM=1&PC=10SOSO4

Source: http://webservices.sys-con.com