Organizations need a mechanism for leveraging context
The current economic downturn has shifted the focus of most organizations from business growth to a simple survival mode. Chief Information Officers are spending more time on difficult cost-cutting decisions than on being more competitive and responding to business change. At the same time, these same businesses predict that Service-Oriented Architecture (SOA) is a critically important tool for helping companies deal with the crisis, since it helps avoid redundant capabilities, reduce IT costs, improve time to market, and position the organization for success once the economy improves.
The question then is what should companies focus on to survive these times while at the same time make the right IT investments to become more competitive when the good times are back. These practices include transparency, a ruthless focus on return on investment, and increased emphasis on governance. Choosing the right tools for SOA Governance that enable organizations to manage assets, promote systematic reuse, and maintain quality in a cost-effective manner is an essential part of not just surviving the downturn, but positioning the organization for long-term success.
Few topics in today’s organizations present such a diverse set of both business and technology challenges as governance. Governance consists ofestablishing chains of responsibility, policies that guide the organization, control mechanisms to ensure compliance with those policies, and communication and measurement amongst all parties. However, what constitutes a policy and what activities and tools the organization requires for governance are questions that have a broad diversity of answers.
Nowhere are the differences among various definitions of governance more pronounced than in the contrast between lines of business and information technology (IT). From the business perspective, top executives as well as government regulators set policies for the organization, which explain in often broad terms how various individuals within the company must act in certain circumstances. From the IT perspective, however, governance covers a range of policies that span the gamut from purchasing and hiring policies all the way to firewall and coding policies and enforcing service-level agreements.
Service-Oriented Architecture (SOA) is a well-adopted approach to organizing IT resources to better meet the changing needs of the business. Governance is essential to ensuring that organizations realize the business benefits of SOA consistently through their IT implementations. Furthermore, as such firms adopt SOA, they become better able to provide more flexible governance overall. The big win for SOA governance, therefore, extends well beyond the SOA initiative and applies the lessons of SOA governance into all parts of the organization.
This paper explores the relationship among SOA, IT and corporate governance, defines the key lessons of SOA governance, and summarizes how these best practices expand well beyond SOA to deliver better governance overall.
Service-Oriented Architecture (SOA) is a set of best practices for organizing enterprise IT resources to support dynamic, flexible business processes. As an architectural approach, SOA is inherently platform, technology, and protocol neutral, so how well leading platform vendors are able to tell an accurate SOA story, while nevertheless seeking to promote their own platforms, is an interesting question.
It’s important to emphasize that it’s reasonable for any vendor to seek to explain how their offerings support their customers’ architecture efforts. SOA, however, sets the bar particularly high, as a core aspect of SOA is organizing heterogeneous resources to better support agile process requirements. It is important, therefore, to contrast how well platform vendors, and in particular Microsoft and IBM, position their offerings to support their customers’ efforts to deal with their inherent heterogeneity, without requiring them to solve heterogeneity problems by moving to a single vendor platform.
Today’s exploding numbers of business events, both combining with and driving the exponential growth of information in the business world, are increasing the need for Business Event Processing (BEP). This increased reliance on business events also leverages thethe collaborative, Internet-based technologies of Web 2.0, as well as Service-Oriented Architecture (SOA), providing a flexible approach to obtaining value from events. The combination of these three approaches provides a foundation for flexibility, visibility, composability, integration, and scalability.
The bottom line, however, is the business story. BEP, combined with Web 2.0 and SOA, are bridging the gap between business and IT better than any of these approaches can separately. Today’s organizations require real time visibility into their business, as well as the ability to process business events to solve business problems, what we call Real World Processing.
Such solutions will have broader impact on the business itself and can create new competitive models in any industry where forward looking companies implement them. Furthermore, companies who exploit the power of BEP will be better positioned to understand threats and take advantage of opportunities, and will therefore have a competitive advantage within their industry.
ZapThink considers runtime SOA governance a requirement of successful SOA, greatly increasing the chances that the SOA implementation will have business value. Indeed, the lack of adequate runtime SOA governance greatly reduces the chances of success. The ability to create and monitor policies, manage performance, secure the system, and provide self-healing mechanisms means the SOA implementation will provide ongoing value through productivity benefits.
However, most SOA stack vendors do not address many of the key requirements of SOA, including solution patterns around runtime SOA goverance. Considering this limitation, it’s important to address these issues with the proper technology, leveraged in the proper way. Thus, the purpose of this paper.
Many organizations look to Service-Oriented Architecture (SOA) to provide greater business agility in the face of evolving business requirements and complex, heterogeneous information technology (IT) environments. To achieve this agility, architects implement a Services abstraction that loosely couples business Services from the underlying implementations of those Services. Building such an abstraction layer is not without risks, however–inherent in building such an abstraction is the risk of sacrificing performance and scalability to achieve the organization’s required agility.
As SOA becomes mainstream, though, enterprises simply cannot afford to trade away performance to achieve agility. As a result, architects must plan for performance up front, as part of their SOA planning process, and leverage a variety of techniques and solutions to achieve performance and scalability as well as business agility as the traffic to their Services continues to increase.
Service-Oriented Architecture (SOA) governance, consisting of creating, communicating, and enforcing the policies that apply to the design, deployment, and management of Services, is one of the most critical, yet confusing, part of an effective SOA plan. One of the reasons why SOA governance is so important, as well as challenging, is that SOA teams must govern the entire Service lifecycle, not just as the team models and develops the Services at design time, but also as they deploy and manage them at run time, and reconfigure and recompose them at change time.
An important part of the SOA infrastructure for enabling SOA governance is the registry/repository. Today’s registry/repositories are fully featured SOA metadata management solutions that coordinate policy activities and enable policy enforcement across the Service lifecycle. As organizations roll out their SOA initiatives, it is important to consider SOA governance as one of the initial steps, and a registry/repository is often the most important, first piece of SOA infrastructure to put in place.
The promised business value of Service-Oriented Architecture (SOA) is driving many enterprises to purchase key SOA-related technologies, such as an Enterprise Service Bus (ESB), in advance of the forthcoming architecture. However, the road to SOA is not always clear, and many enterprise architects, developers, and project leaders require guidance to understand the steps to SOA success. Such guidance must include clear, interactive, and adaptive process that ensures that team members understand all requirements, document all details, and plan all testing and implementation tasks.
The purpose of this manual is to walk those charged with designing and building their SOA implementation through the issues, steps, and procedures they require to create their first iteration of SOA, and how to build on that experience to drive a more systemic change within their enterprise. We’re going to take you through this journey assuming that you have the technology on hand, whether that is an integration server, application server, or an ESB, and focus on the best practices and architectural patterns for that particular category of technology. Since SOA is by nature heterogeneous, strategies for resolving architectural challenges earlier in the lifecycle using well-defined semantics will be discussed.
Systemic to this manual is how to approach testing in the context of SOA. While many consider testing as something that is at the end of the process, it’s actually a part of each step. Thus, as part of this manual we will teach you about testing approaches and key enabling technology.
Service-Oriented Architecture (SOA) is an approach to organizing IT resources to better meet the changing needs of the business. While many organizations are somewhere on their SOA roadmaps, many such organizations face challenges when planning the underlying infrastructure that will support their SOA implementation. One reason for this challenge is that there are three core infrastructure areas that are jointly essential to the success of separate, but overlapping SOA effort: governance, quality, and management.
Governance means creating, communicating, and enforcing the policies that apply to the behavior of IT and its users. Quality is a measure of how well working systems meet the needs of the business. Management focuses on how well those systems meet performance, security, and other non-functional requirements for working software. In the context of SOA, however, these three sets of capabilities begin to merge.
To provide the business agility benefit that is the core business motivation for many SOA initiatives, governance, quality, and management need not only apply to the design time and run time phases that traditional software projects exhibit. In addition, SOA requires these capabilities apply to the change time phase as well, where organizations reconfigure and recompose Services to meet changing business needs. As a result, the governance, quality, and management challenges that SOA presents go beyond traditional IT concerns.