I have found SOA: Bridging the Divide Within IT quite interesting and facilitating. However, I think it is not that smoothly in addressing SOA. Let me be that reckless to take courage of identifying a Business Service and Business Process.
A Business Service = 1) data/facts à 2) meta-data/data meaning/interpretation in the context of the business domain (defined in common knowledge) à 3) rules of data manipulation (modification, aggregation, logical relationship) à 4) rules/scenarios/orders of invocation/execution of the rules of data manipulation à 5) meta-data/data meaning/interpretation of the data
state at some points of scenarios/orders of invocation/execution called results (internal and external meta-data) à mechanisms of delivery of the results to the Business Service Consumers
Other important elements of a Business Service like documentation, audit rules and procedures and alike are skipped for the sake of simplicity. Internal and external meta-data stand for internal meanings of the results and their interpretation for the Business Service Consumers.
A Business Process = 1) rules/scenarios/orders of result exchange between the Business Service à 2) re-interpretation of the results from one Business Service at the entrance point into another Business Service.
At the entrance point into a Business Service, the foreign results become the data/facts. Re-interpretation may be done either in the form of adding additional meta-data (i.e. accepting all or a part of meta-data provided with the foreign results) or replacing some or all meta-data provided with the foreign results with internal meta-data/data meaning/interpretation.
In some custom cases, step 4) of a Business Service is also considered as a Business Process. However, such definition may be taken as a jargon because no business entities are defined for such process; usually the entities are heterogeneous things representing data, applications, communication process, human activities, information containers (like spreadsheet) and alike.
Based on the aforementioned definitions, not every change in the Business Service or Business Process should be reflected in the processes defined by the ITIL for an IT organization. For example, a request for new business feature would not affect IT Change Control service except for its speed in the request processing but it is irrelevant to particular change in the business (it is common requirement the faster IT Change Control works, the better for the business and for the IT). At the same time, such request would directly affect SOA Service or even a Service Orchestration. Thus, Ronald Schmelzers statement if its not possible to apply SOA to ITIL, then we face an impasse the fact that SOA will be relegated to
solving only some of the needs of business is inconsistent (with all respect). SOA and ITIL, in spite of their quite impressive similarity, have different subjects in IT and solve a little bit different IT problems. Nevertheless, I applaud Mr. Ronald Schmelzer for the brilliant idea of enriching SOA knowledge base with experience collected in ITIL.
- Michael Poulin
Gervas Douglas <[EMAIL PROTECTED]> wrote:
SOA: Bridging the Divide Within IT
Document ID: ZAPFLASH-200689 | Document Type: ZapFlash
By Ronald Schmelzer
We often refer to information technology (IT) as if it were one cohesive department within the enterprise. However, for most businesses, IT really consists of at least three separate organizations each with their own technologies, best practices, approaches, and terminology: the systems and network people, the application development and integration team, and the data storage and information management group. It should come as no surprise that this siloed approach to organizing IT leads to inflexibility, and limits ITs ability to meet the changing needs of business.For people who construe Service-Oriented Architecture (SOA) narrowly as applied directly to the application development and integration arena, SOA would be of little help in addressing these broader issues of siloed IT organizations. However, to be most compelling to the organization, SOA should apply to all groups within the IT department. It is important, therefore, to explore how to apply the principles of Service Orientation to the various groups within IT using the language specific to each.SOA and the IT Infrastructure Library (ITIL)
The mantle for well-conceived and executed architectural practices might actually go to the operations part of the IT organization. The most widely accepted source for IT Service Management (ITSM) best practices is the IT Infrastructure Library, known as ITIL®. Developed by the's Central Computer and Telecommunications Agency (CCTA) in the late 1980s, ITIL has rapidly become the de facto standard for managing the most important services that IT provides the rest of the organization. ITIL has become a godsend to companies looking to improve the quality and cost-effectiveness of their IT operations by providing well-documented processes, procedures, and approaches for dealing with the most common business needs of IT. Now managed by the UK Office of Government Commerce (OGC), ITIL consists of a set of documents and a customizable framework of best practices for ITSM. United Kingdom The ITSM context for services that ITIL applies to are processes and functions that provide IT service support (including configuration management, change and release management, incident and problem management, and service desk), facilitate IT service delivery (including management of service levels, capacity, financials, availability, and overall IT continuity), and provides other operational guidance (security management, application and software asset management, infrastructure, and general business imperatives). What has made ITIL popular is that the specifications meet the needs of a very broad constituency. Enterprises utilize ITIL to organize their large, heterogeneous, and often chaotic IT systems, while small organizations use ITIL as a way of instilling best practices without having to reinvent the wheel or make mistakes too early in their companys development. Another key to ITILs success is that it is adaptable to the particularities and differences among enterprises and doesnt attempt to establish a single mechanism for any of the services it attempts to standardize. As ZapThink explored in our Subtleties of Service Convergence ZapFlash, the ITSM context for service is converging with the SOA context for Service. As ITIL-focused services become composable, loosely-coupled Services as part of a SOA implementation, ITIL should instill best practices for managing each of these IT service support and delivery functions. In other words, SOA can learn a lot from ITIL, and vice-versa. After all, ITIL espouses that an organization should move from a technical focus to a service focus. As companies implement SOA, services developed under ITIL should be able to be represented in a Service-oriented manner, leveraging the abstraction, loose-coupling, and composability capabilities of SOA for meeting ITIL needs. In fact, if its not possible to apply SOA to ITIL, then we face an impasse the fact that SOA will be relegated to solving only some of the needs of business.Furthermore, architects looking to implement SOA can also learn from ITIL. ITIL defines a set of artifacts, processes, and documents that help to describe, define, and detail various IT processes, but in an abstract way. In other words, ITIL doesnt provide the specifics for how to implement those processes. After all, ITIL is not a methodology, but rather a framework for specifying process details. It should be possible to borrow some of the artifacts and documents created for ITIL and repurpose them to meet SOA-specific needs for specifying a range of business processes in an implementation-independent manner. In particular, one of the elements of ITILs success is its use of common vocabulary, consisting of a glossary of well-defined and widely agreed upon terms. Another key element is the idea of the Continuous Service Improvement Programme (CISP), which takes an iterative approach to meeting changing business requirements and IT capabilities. Proponents of SOA would be well-advised to take under consideration these same ideas in order to strengthen the overall value and depth of their SOA implementations. In addition, any linkages in vocabulary or process to the way in which ITIL proponents see the world can only serve to improve the overall state of enterprise architecture in the company by unifying the disparate and complementary views of how IT should meet the needs of business.SOA and the Masters of Data
To the people who manage databases, support data warehouses, integrate information, and perform semantic modeling, the business is the data, and the various systems and networks that operate on data are simply tools for manipulating business information. Dealing with data heterogeneity and meaning is just as challenging, if not moreso, than dealing with the integration of heterogeneous systems and networks. In order for any composite application to be a reality, the interacting systems must be able to understand the data that underlie critical business information. In this regard, what is most important to the data specialists are the data and information models that identify how information propagates through the enterprise and how systems can extract meaning from data.To solve these data-specific issues, the data masters in the IT organization craft their own approaches, methodologies, and vocabularies. The data warehousing field spawned many of these efforts, as did various efforts to reach the nirvana of semantic integration in which disparate systems with no a priori knowledge of each other could still understand data passed between them. A number of major data-focused IT initiatives have evolved over the years to deal with disparate data in the enterprise ranging from the Common Information Model to efforts around the Semantic Web and The Open Group's ISO 11179/UDEF (Universal Data Element Framework).Just as it makes little sense to consider ITIL as covering aspects of business and IT outside the scope of SOA, it also makes little sense to consider data and information outside the bounds of Service Orientation either. After all, SOA is enterprise architecture, and as such, provides a broad umbrella that includes approaches to addressing semantic issues. As a result, semantic integration is where the conversation begins with the data-centric IT folks. Rather than isolating them as a separate group, Service contract design and composite application development must happen as a collaborative effort with both the application development as well as the data/information team. Stronger inclusion of semantic and data awareness would considerably strengthen SOA efforts, and vice-versa. Furthermore, the use of and exposure to Services in the enterprise would significantly improve data integration efforts.The ZapThink Take
In a Service-oriented enterprise, theres no reason to keep the different disciplines of IT separate any longer. IT service, network, and systems management can be involved in the SOA conversation every much as the application developers and data masters. Indeed, SOA actually enables the business to bring together these domains with a single cohesive approach for the first time. A true enterprise SOA will have an IT resource and data perspective on Services, and a Service perspective on IT resources and data. For this vision of convergence to be successful, however, each side will need to work with the other and working with people in different groups is one of the greatest challenges of SOA today.
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. __._,_.___
SPONSORED LINKS
| Computer software program | Computer software spy | Computer job |
| Database software | Discount computer software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
__,_._,___
