Role in SOA governance

In the past few years or even decades, IT departments in many large institutions have grown up. These institutions have many applications running on host systems using IMS and CICS; There are also many command-line applications running on UNIX platforms, as well as customer/service and 4GL applications, and even those that are implemented by unfortunate users who use the first generation of object-oriented ideas. Finally, all of this has to be bonded, or in other words: many to different integration technologies, from file interface technology to database replication technology, from API access to screen interface crawl, and RPC, CORBA, and at least two EAI platform integration Technology. Or, to put it another way: Although many big business's it shows up to look like a whole, it's actually a mess inside.

There is a discipline called Enterprise Architecture (Enterprise architecture) that discusses it from a variety of perspectives: logic, modeling, and maintenance, such as how to manage the application mix, how to document these connections, A continuous improvement plan and progressive modernization form the foreground of the application system. But in my experience, most of these are descriptive, and the main purpose is not to force a constantly changing architecture to remain consistent. It's time for SOA to play.

SOA promises to introduce clear boundaries in functional areas that are designed to come from the requirements of the business itself, rather than from the needs of it (there is a good way to refer to the book written by Steve Jone on Infoq). Services become the most basic conceptual element for management, introduction, and development, as well as basic elements for planning and assigning tasks. The service becomes an alternative, modernized existence beyond the source code, and gradually, enterprise it shifts from an application-oriented architecture to a service architecture, which relies on integration, which makes interoperability between autonomic services (rather than exceptions) the default behavior.

Many developers, analysts, consultants, and related practitioners agree that governance is a key element of SOA to ensure SOA success. It sounds like governance is just what it needs when a business moves to SOA, but it can take 10 of years-at least in most of the organizations I know. The governance of SOA therefore needs to be constantly practiced, even if the enterprise's main assets are already service-oriented, and SOA governance is needed.

This article explores a set of potential roles for successful SOA governance needs: The SOA domain architect role, the SOA platform architect role, the service designer role, business service owner, and technical service owner. You can adopt these names, or you can choose a more appropriate term for your current situation, but I believe that the corresponding roles in the tasks that are mentioned in this article need to be formally granted in various situations, ensuring that SOA can achieve all the commitments it makes.

Next we discuss each role in detail.

Service Designer

Designing a service requires understanding both technical and business-related skills. A service designer can be viewed as a technical business analyst in skill requirements, or as a senior developer with a lot of domain knowledge compared to a technical expert. The task of a service designer is to make a good service design, which means that he or she needs to find the right balance between the appropriateness of a particular problem and the reuse of different multiple common scenarios.

To be able to design a service, the service designer needs to decide how to aggregate the action (if you adopt the classical style of SOA) into an interface, which means deciding whether a single service is expressed as a collaborative service or as a stand-alone service. He or she also needs to decide how to name these operations and services, how granular a service should be, whether it relies on existing services, how to handle error situations, whether it will have an impact on the quality of certain services in the future, and consider services from a holistic perspective.

Consider a controversial topic: Because XML prescribes the basic format for document exchange between the consumers of services in a large number of organizations and providers of services, a service designer absolutely needs to have good (if not the best) knowledge of XML and its associated standards and technologies, especially XML Schema (XSD), namespaces, as well as common XML design principles. Most of the time, service designers can rely on tools that support these standards and technologies, but no matter how good the tools are, it is important that he or she understands what is hidden behind the tools.

The design of services is not independent of each other, although the goal of service is to achieve self-government. This is particularly true in input and output documents, which typically depend on the XML Schema fragment library that is already well designed. A service can (and should) reuse an existing service. For this reason, service designers need to be able to access a repository of information that exists. In the discussion of the role of the official in this article, in general, these repositories may be a folder for a shared server, a simple Access database, or a commercial (or Home-grown) Registry/repository solution.

So how do you do it in terms of governance? Service designers have to follow certain rules and guidelines in their work. For example, there may be some special rules for governance before the service designer starts their work. Or when the service component migrates from a service lifecycle to the next lifecycle. The granularity of a service, or the clustering of services (meaning that services are organized in groups, domains, or otherwise). In the day-to-day work of the service designer, there are many other governance provisions in the company's SOA policy, so it is fair to say that the service designer is the primary user, or key customer, in a corporate governance framework.

SOA Domain architect

In many organizations, there is a complete group of service designers who are either responsible for individual business units or serving the entire company. The reason for this group is that it is unrealistic to think that there is a single service designer who can design all the services of the company. The SOA domain architect is responsible for ensuring that the things that individual service designers design are consistent and of high quality within the company. In many ways, this means that the SOA domain architect is the chief Service architect, and in fact, giving a service designer this extra role may be a good start, even if it doesn't. Domain architecture It is also important to have at least the work of a service designer (like a good application architect should also be able to assume the job of a programmer).

The SOA domain Architect's responsibilities include being a final decision maker in the event of a conflict in the design of a service, deciding whether to modify a service, replace a service, or expand a service. He or she will consider the dependencies between services as a design authority and must ensure that not only all consumer/provider relationships are properly documented, but that the company's service model remains consistent.

From a business perspective-if you can, for an enterprise architecture design team (for example, the basic task of the SOA domain architect is to discover business value (relative to technical value, as described below).

SOA Platform Architect

Infoq has many discussions about what is the right SOA technology, but whatever technology you choose, the potential for SOA can only be achieved if you are technically consistent. In other words, whether SOA is web-based service, rest, CORBA, or Java and JMS, or C # and MQ, or any combination of technologies, it can be done perfectly. But once they have made a technical choice, they need to be limited, either by selecting it from this (or slightly larger) list of technologies, or by limiting it to a small technical mix.

The first task of the SOA platform architect is to determine these choices. For example, a standard set is OK, and the convenient assumption for discussion is a Web Service compatible with WS-1 Basic Profile 1.2, combined with ws-addressing, ws-reliablemessaging, and UDDI v3. The SOA architect will be responsible for maintaining the technical inventory. For example, there may be new standards to be adopted, or technically alternative, such as restful HTTP can be introduced, and products--perhaps never the technical basis of the entire SOA architecture, but it can only be used to implement soa--needs to be evaluated and possibly introduced. Ultimately, the composition of a company-wide SOA encompasses not only business-related services, but also technical services such as authorization, conversion (transformation), user settings, and so on. For technical services, the SOA platform architect acts as the architect of the SOA domain (i.e., the domain is the platform).