Showing posts with label SOA Success. Show all posts
Showing posts with label SOA Success. Show all posts

20 March 2008

Besides Reuse, How Else Can Soa Bring an Organization Success?

SOA Service Oriented Architecture Articles : Besides Reuse, How Else Can Soa Bring an Organization Success? Author: 10x Marketing

Service Oriented Architecture, SOA is helping businesses uncover buried content, reuse that content to streamline business processes as well as turn a profit on existing data. As companies build more and more software systems, they are seeing similar patterns and situations appearing. The new request from organizations is a solution to reuse the functionality of existing systems rather than create them from scratch each time. Along with reuse comes decreased infrastructure redundancy and increased time to market.

Reuse ability is indeed one of the best things about an SOA service but how else can SOA improve businesses? Some SOA services provide businesses with enterprise search which enables organizations to query within their own contentbase, as well as manipulate and render content in a distributed environment. SOA services allow organizations unprecedented ability to integrate, access, use, and reuse their content in multiple ways across multiple channels.

Organizations can develop content applications that can access any of the services running on the SOA, including legacy applications that utilize an XML wrapper, ensuring that companies can migrate to a modern SOA-based publishing architecture while leveraging the full benefits of their existing platforms. For large publishing organizations, content heavy enterprises like government and insurance companies for example find great relief with an SOA structure.

Organizations can reap in profits from already existing content and also reduce costs with less money spent on IT. Businesses can save money with an SOA system and scale down their current IT department but not remove the IT department all together. In fact, business processes are only streamlined by having the two together.

So to answer the question, are there other reasons to purchase an SOA service? A straightforward yes to answer that question. SOA will deliver value to the business in multiple ways beyond reuse.

17 March 2008

Model offers measure for SOA success - Part 2

SOA Service Oriented Architecture Articles : Model offers measure for SOA success By Jon Bachman

Level 4: Measured business services

Want to compare network applications products? Visit the IT Buyer's Guides now.
Level 4 provides continuous feedback on the performance and business impact of the processes implemented at Level 3. The key focus at this level is collecting data and providing that data to business users, enabling them to transform the way they respond to events.

In our example, a Level 4 project could introduce logging and a service to monitor business activity. These functions provide a collection and display process for business managers to view their trade routing operation and for compliance officers to monitor trading behaviors of their staff and customers.

Level 5: Optimized business services

At this final level, business-optimization rules are added, and the SOA becomes the nervous system for the enterprise. Automatic responses to the measurements and displays of Level 4 allow an organization to take immediate action on events.

A Level 5 project can take the request messages entering the ESB and route that information to an event-stream processor. This service correlates the behavior of all traders across multiple execution venues and identifies important patterns. This information might be used to execute new trades or stop a rogue trader who is out of view of compliance officers.

The SOA Maturity Model provides a framework for IT and business users to properly evaluate the applicability and benefits of SOA in an organization.

Bachman is senior director of product marketing at Sonic Software. He can be reached at jbachman@sonicsoftware.com.

Source: http://www.networkworld.com/news/tech/2006/021306-soa.html?page=2

Model offers measure for SOA success - Part 1

SOA Service Oriented Architecture Articles : Model offers measure for SOA success By Jon Bachman

Service-oriented architecture has emerged as the most significant shift in how applications are designed, developed and implemented in the last 10 years.

A consortium of software vendors and consultants recently introduced the SOA Maturity Model, which is designed to provide IT decision makers with a framework for benchmarking the strategic value of their SOA implementations and planning. The model is divided into five levels.

Read the latest WhitePaper - Wait-Time Analysis Method: New Best Practice for Performance Management

Level 1: Initial services

At the initial stage, an organization creates definitions for services and integrates SOA into methodologies for project development. In a financial-services environment, a Level 1 project may use an application server or an enterprise service bus (ESB) adapter to create Simple Object Access Protocol and HTTP Web service invocations between a management system that places an order and a trading service that accepts the order.

Want to compare network applications products? Visit the IT Buyer's Guides now.

Level 2: Architected services

At this stage, standards are set for the technical governance of an SOA implementation, typically under the leadership of the architecture organization. Standard SOA infrastructure and components, such as an ESB, a services and policies repository, an exception-management service, a transformation service and a single sign-on service, are used to foster greater reuse of services, as well as provide tight management and control of services across an organization.

Level 3: Business services and collaborative services

Level 3 features the introduction of business-oriented services, such as business process management (BPM). With a focus on the partnership between technology and business organizations, Level 3 optimizes the flexibility of business processes, allowing IT to respond quickly to changing business requirements.

For example, a Level 3 project utilizing BPM might use a Universal Description, Discovery and Integration registry to find a funds-transfer service that could significantly reduce settlement times. This service would be connected to the ESB process within hours of recognizing the business need.

Source: http://www.networkworld.com/news/tech/2006/021306-soa.html

14 March 2008

10 Steps to SOA Success

SOA Service Oriented Architecture Articles : 10 Steps to SOA Success By Sandy Carter

For every service oriented architecture (SOA) success story, there lays an abandoned SOA project stuck in one of the various stages of deployment. Underscoring the successes and challenges of an SOA is the popularized theory that fifty percent of IT projects are deemed unsuccessful. This, of course, can make embarking on an SOA strategy rather intimidating.

Still, SOAs remain at the top of the executive and IT agenda based on their ability to more closely align technology with the needs of the business. Quickly dismantling the high statistics associated with IT project failures, SOAs have shown demonstrable ROI—so much so that the proven successes of SOAs have enabled this segment to swell to a worldwide market opportunity of $60.3 billion. This growth is up by 75 percent compared to 2005 when the market was estimated at $34.6 billion. Moreover, the SOA market is expected to skyrocket with an anticipated 54 percent continued growth through 2008 to reach $143 billion (Gartner).

Furthering the growth of the SOA market is the strategy's ability to pay for itself quickly. In fact, the number of opportunities for quick return on investment can be surprising. For example, many organizations are unaware of the number of duplicate processes that occur in separate departments and applications—and how much these duplicate processes are costing them. When you examine the costs and lost revenue attributable to redundant function and duplicated effort, you begin to see the value of centralized services over having to manage multiple competing and overlapping functions.

Still, there are some watchers out there asking, 'how can SOA succeed where previous approaches have failed?' and 'how do I avoid becoming a statistic?'

These are powerful questions. Simply stated, a successful SOA strategy can be achieved because the standards, best practices, and governance models have finally matured to the point where reuse can actually work. After all, SOA is, by definition, an architecture as well as an approach to IT that can help solve immediate business challenges.

Although each company has different business needs and each industry faces its own set of challenges, there are common issues that can lead to the failure of an SOA. The ten most prevalent are:

  1. Secure executive sponsorship: Before presenting how you'll ensure your company's SOA success, be prepared to demonstrate successes and failures of other companies on their path to SOA and articulate how you'll emulate proven practices and avoid pitfalls.
  2. Align the troops: Converse to overcoming the obstacle of executive support for your SOA is the challenge of aligning your organization to work and think in new ways. To do this, identify and recruit critical champions for each part of the business who will support and even evangelize the SOA efforts.
  3. Consolidate views: Eliminate the multiple views of information that are currently floating across your organization so that you are only looking at a singular, comprehensive, and consistent view of the business.
  4. Reuse equals re-useful: Identify and maintain a repository of your current Web services to avoid duplication of efforts. You may be surprised how much work has already been done by different pockets of your organization.
  5. Integrate the silos: Although in theory many of today's IT organizations seek to integrate and avoid redundancies while maximizing their current IT investments, the reality is that extraordinary efforts are being spent on still trying to maintain different IT systems that co-exist but are not integrated. The penny wise, pound foolish approach to SOA simply does not work.
  6. Seeing the forest through the trees: Remember that an SOA is an architecture, not a combination of clumsily bundled together point products that need to be force fit. A true SOA is created with an open standards-based approach through four strategic stages: model, assemble, deploy, and manage.
  7. Hop on the Enterprise Service Bus: An ESB provides the much needed connectivity infrastructure that you can use to integrate services within an SOA. Together, SOA and an ESB help to reduce the number of complexity of interfaces, enabling you to focus on your core business issues, rather than on maintaining your IT infrastructure.
  8. Step-by-step: When the thought of rolling out an enterprise-wide SOA becomes overwhelming, remember that the best approach is to continually test and modify while rolling it out—first departmentally then slowly throughout the organization—to identify issues while adding to your arsenal of best practices along the way.
  9. Avoid the carpe diem approach: Remember that you're not building your SOA just for today or this year. This is an organization-wide approach to aligning IT with the needs of the business and must accommodate today's needs as well as those of the future. For example, be sure to include support for mobile and wireless devices as well as ensuring you have enough flexibility to support 'the next big thing.'
  10. Prevent the accidental SOA: Many organizations may discover that they have a healthy repository of Web services that will comprise the majority of their SOA, though don't believe that the SOA starts and ends with a collection of Web services. Remember that an SOA must go beyond Web services to support all of your business processes. It must also provide a flexible, extensible, and composable approach to reusing and extending existing applications and services as well as constructing new ones.

So, if you've been hesitant to initiate an SOA project this year, make it your New Year's resolution to better align your technology with the needs of the business and join the legions of developers driving revenue up and cost out of their companies. Follow these ten steps and you'll be on your way to success.

About the Author
Sandy Carter is the vice president for SOA and WebSphere strategy at IBM. As IBM VP, Sandy has worldwide responsibility for marketing, strategy, and channels. During Sandy's tenure, the WebSphere portfolio has grown 18% in 2005 over the prior year and is in its 26th consecutive quarter of growth. Her influence has significantly strengthened the WebSphere brand through IBM's acquisitions of Gluecode, Ascential, and DataPower Corporations, and she has led WebSphere to win seven industry awards.

Source: http://www.developer.com/design/article.php/3653576

13 March 2008

10-step program to SOA success

SOA Service Oriented Architecture Articles : 10-step program to SOA success by Dave Chappell

Commentary--One of the best parts of my job is meeting with people to discuss their technology initiatives. In the past couple of years alone, I have traveled around the world several times and met with thousands of people at public SOA forums and in private gatherings.

This group consists of architects, developers, project leaders and CIOs--and they are at varying stages of adopting SOA, from just dipping their toes in the pool to full scale implementation.

The most rewarding thing for me is when I get a chance to engage in and facilitate a conversation with a room of people that includes those who have successfully completed SOA projects. Listening to these "pioneers" share their experiences, both positive and negative, with those still trying to figure out SOAs is an eye-opening experience.

Across all of these situations, and there have been many, I have noted a consistent set of themes which I have rolled up into what I will call the 10-step program to SOA success.

1) Who's Your Daddy? Very few CEOs or CFOs give a damn about SOA, architectures, ESB's, or any of that. Find someone on the business side of the house who is responsible for a top business imperative, convince them the project will make money and let them champion your cause. Without this, the next nine points don't matter.

2) Have a Vision. Be prepared to articulate your vision regularly and consistently. This seems like a "duh," but it's what helps you gain support from other teams, across departments, and from your upper management. You are putting an architecture in place that is going to prevail for decades to come.

3) Identify Attainable Projects. Armed with your long term vision, choose an initial project that has immediate value--one that you can accomplish within a few months. Nothing speaks louder than a successful project delivered on time and on budget.

4) Support the Business. Find the business initiatives that matter most and you will ensure that your SOA projects get the attention they deserve. These usually have to do with improving operational efficiency and/or increasing top-line revenue by attracting and retaining customers.

5) Flexibility Matters. Create flexibility through loosely coupled services that can be put together to form composite applications that automate business functions. A flexible infrastructure, such as an ESB and Eclipse-based tools, provides business processes that are capable of adapting to change as quickly as market needs dictate.

6) Networking is not Just for Salespeople. You have to establish corporate-wide support at all levels of the organization. Development teams, datacenters and business units will have to share data and business logic across processes that span traditional boundaries. This may seem like an unnatural act to some, but it's the only way to be successful.

7) Don't Lose Control. Establish strict governance procedures from the outset. With stringent government regulations such as Sarbanes-Oxley, organizations need to be acutely aware and be held accountable for their book-keeping practices. In the software sense, this means monitoring, auditing, and reporting of daily business transactions. An out-of-control SOA may spell doom for the project and, much worse, it could cause damage to the company.

8) Don't Fear Change. Organizational changes are imminent in order to address cross-cutting issues that arise. For instance, these issues may include new areas of ownership for business processes that span application silos and new governance models to enforce policies. SOA is a corporate wide initiative and you need to be a team player to make everyone successful at it.

9) Learn as You Go. Nobody gets it right the first time. The first project or two provides tremendous insight into what works well, and what things can be improved. The successful aspects of each project should be recognized, captured and carried from one project to the next. These successful aspects may be software based or organizationally based.

10) The Best and the Brightest. Finally, create an SOA Center of Excellence--a team that will be responsible for addressing the new organizational issues surrounding the adoption of SOA. This diverse group, including architects, project managers, business analysts and, most importantly, someone from the senior executive team, will ensure that the priorities of the SOA project are constantly moving forward and delivering measurable results.

biography
Dave Chappell is vice president and chief technology evangelist for Sonic products at Progress Software.

Source: http://news.zdnet.com/2100-3513_22-6108621.html

04 August 2007

Wachovia’s steps to SOA success

Wachovia’s steps to SOA success - How Wachovia revamped its organization to successfully implement service oriented architecture SOA - By David L. Margulius

Rather than simply create a few services to be shared by applications, Wachovia Bank’s goal was vastly more ambitious: to transform its organization with a flexible new service oriented architecture SOA infrastructure. Here’s the step-by-step plan.

1. Map the future and work toward it. Identify the business and IT goals and create a map of the new, improved organization to serve as a target.

2. Define the components. A flow definition of business and infrastructure components, and who should be assigned to each, is essential.

3. Fill in the details. Create detailed descriptions of all the known components, services, and frameworks involved in the desired service oriented architecture SOA end state.

4. Determine the dependencies. Map the interrelationships between all the components, services, and frameworks you have defined.

5. Create a value map. Calculate the increase in technology, spend to achieve service oriented architecture SOA goals, and show how operating costs will decrease over time.

6. Outline the business value chain. Map all the business functions that will be affected and how they interrelate.

7. Model data services. Create a comprehensive picture of data services, from repositories to applications, including any translation layers.

8. Build a business and infrastructure runtime model. Draw up plans for how components, services, and frameworks will operate in concert when the service oriented architecture SOA is deployed. These plans will stretch from business services to authentication/authorization.

9. Create a utility management model. Ideally, the infrastructure underlying service oriented architecture SOA should be as agile as service-based app dev. Plot out everything from SLA management to capacity usage and planning.

10. Create a timetable. A detailed road map for components, services, and frameworks clarifies internal IT goals and manages business expectations.

11. Draw up a dynamic efficiency map. A continually updated chart shows which services have been deployed in which areas and which business units are consuming them.

12. Automate management and tracking. The automated collection of service metadata — and cycling it into reporting and management — is an essential and often overlooked aspect of an effective service oriented architecture SOA.

Copyright 2007-2010 © SOA Service Oriented Architecture. All Rights Reserved