Service Orient Or Be Doomed

SERVICE ORIENT OR BE DOOMED! How Service Orientation Will Change Your Business AUTHOR: Jason Bloomberg & Ronald Schmelzer PUBLISHER: John Wiley & Sons, Inc. DATE OF PUBLICATION: 2006 258 pages

THE BIG IDEA Introducing service orientation as a vision and philosophy that can greatly impact a business, this innovative new book equips the reader to: Best use technology resources to meet goals Unleash their “inner nerd” to embrace IT as part of their business as a whole Address the “mother of all business problems”: inflexibility Know the technological factors that pressure a business to innovate Understand buzzwords with Jargon Watch sidebars

WHY YOU NEED THIS BOOK This book offers a magna carta to CEO’s and small business owners that teaches them to erase the line between business and technology , toward a new service-oriented approach which is a synergy of both.

IMPEDIMENTS TO AGILITY Here are the key impediments to making business agility happen in today’s companies. Most of these impediments fall into three broad categories: Complexity . Today’s enterprise environment contains many different people, processes, and departments that work in many different, and often conflicting, ways. Inflexibility . Companies tend to fall into the “if it works, don’t screw with it” mode of thinking, which works well when business requirements don’t change but significantly impedes agility when companies are faced with new situations.

IMPEDIMENTS TO AGILITY Brittleness . This is the risk of failure and other problems that result from excessive complexity and inflexibility - the company cracks with the slightest of pressure. Many small companies can’t deal with unplanned change because they simply have insufficient resources, they’re operating at their maximum capacity, or their centralized management is simply resistant to change. The challenge for companies both large and small, then, is to develop a culture, infrastructure, and resources that enable them to change on a dime as changing needs emerge.

WHY CROSSOVER PROFESSIONALS ARE SO IMPORTANT The reason why we’re taking the time to discuss the issue of business-savvy techies and tech-savvy businesspeople is because the long-term trend in the business world is toward a future where there’s no separation between business and technology in the typical operations of an enterprise. In this vision, all technology is simply a business resource to meet business needs, just like office furniture or human resources or finance. Furthermore, the day-to-day work of businesspeople will become steeped in technology – a trend we’re actually seeing today, with all the phones, Crackberries, and the like that today’s business executive have to carry with them at all times.

WHY CROSSOVER PROFESSIONALS ARE SO IMPORTANT It will simply become impossible for businesspeople to run their daily lives without deep immersion in technology, and it will be impossible for the technical part of a business to operate without a strong business mandate. The two are bound to be intertwined .

LOOSE COUPLING AND COMMON KNOWLEDGE Contracts between providers and consumers of IT functionality work the same way. Even when the same company (or department) controls the provider and consumer in a particular interaction, it often still makes sense to put only enough detail in the contract to stipulate how systems interact at an arm’s length, without going into detail as to how each party will perform its obligations. Loose coupling results from having contracted interfaces that make it much easier to update how each piece of software works independently of the others , since the contract specifies all the information about how each component must interact with other components. In other words, contracted interfaces provide increased flexibility, without giving out too much insider information.

METADATA: THE SECRET SAUCE Just as legal contracts make for solid business relationships, software contracts make for solid, loosely coupled distributed computing. Here’s what goes into a contract, especially the kind that computers, rather than people, need to understand: Contracts should describe what a provider will give to any consumer that chooses to abide by the terms of the contract. The contract should define what functionality the provider provides, what data it will return, or typically some combination of the two.

METADATA: THE SECRET SAUCE Contracts must have information both about the responsibility of the providers for providing their functionality and/or data as well as the expected responsibilities of the consumers of that information and what they will need to provide in return. Contracts also specify the rules of engagement between consumers and providers, known as policies , that govern who can access a provider, what security procedures the participants must follow, and any other rules that apply to the exchange.

ENTER SERVICE ORIENTATION There’s no assumption that Services must be on the same system or even in the same country. Rather, the whole idea of Service-oriented integration is to compose Services regardless of their underlying technology. If we can compose Services together in an agile way such that changing business assumptions simply changes the composition, rather than the implementation, we can get away from having to spend money in times of change, let alone during routine maintenance.

ENTERPRISE ARCHITECT’S ROLES AND RESPONSIBILITIES What we are looking for is an enterprise architect who is able to merge the worlds of business and IT in order to make Service orientation a reality. Such an architect should be able to perform these functions in the organization: The Great Communicator . An architect can translate ill-defined, abstract, or incomplete business requirements into a set of Service definitions or a model for how to define those Services in spite of ongoing, unpredictable change. The Simplifier . The architect needs to simplify the complicated morass of IT technologies and infrastructure into a set of reusable Services and contracts that define the obligation of IT to meet ongoing, changing business requirements.

ENTERPRISE ARCHITECT’S ROLES AND RESPONSIBILITIES The Evolutionist. Architects need to be able to implement technologies and approaches that help them encapsulate changing requirements into metadata as well as maintain the evolving set of Services in the company. Champion of Thrift . They must be able to find ways to reduce the need to invest in unnecessary technology and allow companies to build systems that can evolve with changing needs.

ENTERPRISE ARCHITECT’S ROLES AND RESPONSIBILITIES The Pragmatist . Good architects must be more than great communicators, simplifiers, and economic magicians – they must also be able to make realistic, stepwise improvements to the business use of IT. Master of Best Practices . Good architects will have the opportunity to not only define a business’ overall approach to architecture for the years, and perhaps decades, to come, but might even have an impact on the IT industry as a whole.

SOA (SERVICE ORIENTED ARCHITECTURE) FILLS THE GAP FOR INTERNET B2B The business benefits of Service-oriented B2B integration over the previous, tightly coupled approaches of EDI are clear: Enterprises can reduce the costs of integration because they have agreed on the interfaces between their systems and businesses in advance – reducing the dependency on complex, expensive, and/or custom integration approaches. Enterprises can reduce the total cost of ownership of heterogeneous systems since standards-based, interoperable systems give businesses more choice of vendors and the flexibility to solve their specific business needs.

SOA (SERVICE ORIENTED ARCHITECTURE) FILLS THE GAP FOR INTERNET B2B Enterprises can realize a significantly expanded market opportunity since rather relying on partners and suppliers to implement specific, proprietary technology approaches, vendors can provide solutions that will work in their customers’ environments, allowing them to reach partners and business opportunities that may have been inaccessible in the past. Enterprises can reduce their time-to-market because they can increasingly depend on critical architectural and infrastructural elements to exist in their partners’ IT environments and rely on the interoperability of those elements to reduce their need to develop time-intensive, expensive, and proprietary solutions.

WHO IS THE SOA CHAMPION? However, the SOA champion need not be the person who is driving the overall SOA effort, or even the buyer or the buyer’s boss. Indeed, SOA champions might in fact fill other roles in the organization. The role they play also impacts how they must go about their champion duties: The chief information officer . CIOs have responsibilities on both the business and technology aspects of a company, as well as the power and budget to make things happen. The chief architect . He is either responsible for the overall corporate IT architecture strategy or is the member of the enterprise architecture team who has executive-level responsibility for the overall IT architecture and how it should meet the needs of the business.

WHO IS THE SOA CHAMPION? An LOB executive . Business executives have the combination of technical depth and architectural vision to champion SOA. In organizations lucky enough to have such a person, he or she often can derive substantial business value out of the SOA initiative. A senior architect . These individuals must take the role of evangelists, communicating the value of SOA to every audience that will listen. They must be charismatic, thick-skinned, and determined.

WHO IS THE SOA CHAMPION? An IT manager . These managers tend to work within a particular department or IT silo, and can drive SOA initiatives from within their group due to their technical expertise. Therefore, such champions must have some sort of political edge: the authority to drive such cross-departmental change, a special advantage due to their communication or technical capabilities, or some other asset or expertise that they can bring to the table and push the SOA initiative to its fruition.

BUILDING CROSS-FUNCTIONAL TEAMS IT departments must make a few additional organizational changes to ensure that the new cross-functional teams are effective: Employ an IT-dedicated financial officer . It is probably fair to say that most folks in IT don’t have an adequate understanding of finance and business economics in the first place to understand how their department will positively impact the business. Give architects dotted-line responsibility to the CIO . Architecture is one activity within IT that is not focused on the tactical issues of implementing technology or meeting short term business requirements. Rather, architecture is the practice of dealing with ongoing and unpredictable business change.

BUILDING CROSS-FUNCTIONAL TEAMS Implement metrics for each Service . Services represent current and future business requirements. Therefore, companies should measure the effectiveness of a Service by how well it meets the business requirements, instead of evaluating the underlying IT systems that implement that Service. Compensate IT right . It’s important to compensate IT employees on key business metrics, such as financial performance, customer satisfaction, the ability to meet deadlines, the reduction of overall business spending, and quality metrics.

BUILDING CROSS-FUNCTIONAL TEAMS Aim for transparency . In order for IT to enable businesses to respond in an agile, flexible fashion, IT must be sufficiently transparent to the business so that it can see where the bottlenecks and opportunities are.

FOUR PILLARS OF SERVICE-ORIENTED DEVELOPMENT Specifically, companies must understand four pillars of Service-oriented development: Pillar 1: Interactive Development . Business analysts must work iteratively with business users, both to satisfy the original requirements and to maintain agility as those requirements change. Likewise, developers must continually iterate their code to satisfy ongoing changes to the Service contracts. Pillar 2: Use involvement . The meta-requirement is for a system that responds well to change, and as a result, the requirements definition phase of any Service-oriented project is actually a set of ongoing activities. At no point does design stop and deployment begin. Rather, development is ongoing, as is user involvement.

FOUR PILLARS OF SERVICE-ORIENTED DEVELOPMENT Pillar 3: Contract-first development . Business analysts work with users to distill requirements into contracts that then act as marching orders for the developers. Such metadata represent both the requirements and the test plans that analysts can execute to guarantee that Services meet their requirements. Pillar 4: A Service-oriented company should become more efficient, flexible, and agile over time as they squeeze out necessary complexity, redundancy, and costs iteratively over time.

WHAT DOES IT ALL MEAN? If other parts of the business can facilitate agility, so too can IT. Agility requires a fundamental change in IT, and that change is on its way. Companies that can negotiate this change successfully will have significant advantages over their lumbering, inflexible competition. Those who can adopt SOA successfully will thrive and flourish, and those that don’t will be doomed.

BusinessSummaries.com is a business book Summaries service. Every week, it sends out to subscribers a 9- to 12-page summary of a best-selling business book chosen from among the hundreds of books printed out in the United States. For more information, please go to http://www.bizsum.com. ABOUT BUSINESSSUMMARIES

Service Orient Or Be Doomed

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Service Orient Or Be Doomed (20)

More from Business Book Summaries (20)

Recently uploaded (20)

Service Orient Or Be Doomed