SOA Architecture Considerations · Architecture (SOA) and Enterprise Interoperability environment...

SOA Architecture Considerations

A White paper

Keshav Deshpande

[email protected]

K. Deshpande 8/7/2008

CONTENTS

1.0 INTRODUCTION ................................................................................................................... 3

2.0 SOA PHILOSOPHY ................................................................................................................ 3 2.1 Coexistence with the Past .............................................................................................. 3 2.2 Levels of Integration ...................................................................................................... 4

3.0 SOA ARCHITECTURAL COMPONENTS AND DEFINITIONS ..................................... 5 3.1 Enterprise Service Bus ................................................................................................... 5 3.2 Service Registry ............................................................................................................. 5 3.3 Service Provider ............................................................................................................. 6 3.4 Service Component ........................................................................................................ 7 3.5 Service Contract ............................................................................................................. 7 3.6 Application Adapter ....................................................................................................... 8

4.0 SOA – A LAYERED APPROACH ......................................................................................... 8 4.1 Service Component Layer .............................................................................................. 8 4.2 Business Process Layer .................................................................................................. 8 4.3 Business Function Layer ................................................................................................ 9 4.4 Composite Application ................................................................................................... 9

5.0 SOA – THE BIG PICTURE .................................................................................................. 10

6.0 SOA EVOLUTION ................................................................................................................ 11

7.0 SOA REALIZATION ............................................................................................................ 12 7.1 SOA Realization Maturity Model ................................................................................ 13

7.1.1 Maturity Level I: Service Enablement .......................................................... 14 7.1.2 Maturity Level II: Process Enablement ........................................................ 14 7.1.3 Maturity Level III: Business Integration and Optimization .......................... 14

7.2 Comparing the SOA Realization Maturity Levels ....................................................... 15

8.0 INTEGRATED SERVICE-BASED APPLICATION LANDSCAPE ................................ 16

9.0 THE “WHY” OF SOA GOVERNANCE ............................................................................. 17

10.0 GOVERNANCE ACROSS THE LIFECYCLE - IMPLICATIONS ............................... 18 10.1 Participation ............................................................................................................... 19 10.2 Organizational support ............................................................................................... 19 10.3 Service Ownership and Portfolio Management ......................................................... 19 10.4 SOA Funding and Project Management .................................................................... 20 10.5 Infrastructure & Tooling ............................................................................................ 20

11.0 GOVERNANCE IMPLEMENTATION APPROACHES ................................................ 21 11.1 Addressing disparate frameworks and methodologies ............................................... 21


1.0 INTRODUCTION

An important part of analyzing necessary capabilities for a future Service Oriented Architecture (SOA) and Enterprise Interoperability environment is to envision, explore and lay out the core architectural principles and templates of a holistic service-based organization. By defining a notional landscape of patterns and best practices, a clearer picture of the integration between application architectures and integration architectures can be developed. This document establishes such a notional landscape that will annotate the process of evolution of a set of executable and implementable standards and guidelines to be applied to SOA-based initiatives.

This document also addresses the basics of the SOA infrastructure necessary to facilitate the interoperability requirements and goals such an initiative. It also explores major steps that can be followed in developing an overall SOA, along with design guidelines, and methodology for development of service components.

A major goal of this document is to provide the basic architectural template for promoting interoperability and information sharing among applications, consisting of progressive architectural maturity model. It is obvious for such an environment to operate, existing applications and systems will have to be thought of as cogs in the wheel, rather than traditional stove-piped, containers of functionality. In other words, the functionality contained within these stove pipes will need to be discovered, mined, and exposed as generic services. This alludes to a judicious combination of top-down and bottom-up service analysis and service discovery methodologies, a sort of a happy compromise, meet-in-the-middle approach.

This document does not address another critical area: SOA governance, which will be addressed in a separate white paper.

2.0 SOA PHILOSOPHY

2.1 Coexistence with the Past

In general, SOA emphasizes availing of, and integrating with, existing (legacy and as-is) functionality, applications, and data sources. This is accomplished by exposing currently existing (legacy and as-is) functionality and applications as services, so that they become candidates for maximum reuse.

This does not imply that no new (future or to-be) functionality and applications will be needed, or that an SOA is merely constituted of existing applications with thin service wrappers. In fact, in the course of systems analysis of existing systems and applications, it is usually discovered that there is a critical need for new applications and functionality. This new functionality and the new applications that will be written to support it, is part of the overall systems analysis process, and form an integrated, holistic SOA application ecosystem.


SOA adopts an all-embracing paradigm, where existing applications and functionality are viewed as potential reusable assets, and where both existing (legacy and as-is) applications and functionality cohabit, coordinate, and coexist with to be applications and functionality. This weaving and co-existence of legacy and new functionality into a new IT ecosystem, and viewing them as reusable services, leads to newer and more efficient ways of conceptualizing, modeling, realizing, and conducting business.

2.2 Levels of Integration

In an SOA, interoperability and integration between applications is visualized as occurring at the following levels:

Data level

Application level

Data level integration happens when a unified, integrated view of data is required. This method of integration is also viewed as carrying the biggest risk of data inconsistency, since the data resides in multiple, disparate locations (data sources) and often, exists in incompatible formats.

Application level integration typically incorporates business logic along with data, providing the most value-add in terms of high fidelity of data, coupled with enhanced functional interoperability.

In general, it is discouraged to provide direct access to the data sources; instead, provide loosely coupled interface layer to the applications owning the data. This layer then accesses, integrates, and aggregates this data into a single logical view, making it more relevant to the business. It provides mediation and data transformation capabilities to a common, reusable data specification such as an Enterprise Logical Entity Model (ELEM), thus promoting reuse and application interoperability.


3.0 SOA ARCHITECTURAL COMPONENTS AND DEFINITIONS

This section identifies and defines the constituents of the SOA infrastructure information sharing environment and provides relevant definitions to concepts and ideas, which are referred to within the rest of this document. Note that these components constitute the middle-tier of the overall information-sharing environment.

Enterprise Service Bus

Service Registry

Service Provider

Service Provider Security Implementation

Service Component

Service Contract

Application Adapter

3.1 Enterprise Service Bus

The Enterprise Service Bus (ESB) is the backbone of the SOA infrastructure, providing standards-based, event-driven, and messaging-based interoperability between applications. It also serves as the architectural abstraction layer where disparate operational applications and their functionalities are exposed as Web Services.

The ESB provides mediation facilities between these applications to achieve interoperability. It also serves as the foundation upon which these services can be orchestrated and choreographed to build more complex applications while retaining the benefits of loose coupling and reusable assets.

3.2 Service Registry

The Service Registry provides the ability to register, publish, discover, and govern business services, and is an essential component of the SOA infrastructure. However, while this is an essential function, the overall SOA infrastructure requires a broader array of service-related metadata and artifacts than just WSDLs. These include XML schemas, BPEL descriptions, XSLT transforms, and many other such metadata. Such artifacts also need to be centrally accessible to promote the benefits of reuse and control, and standard ways of storing and retrieving them. The Service Registry provides capabilities to warehouse all such artifacts as well. Another important function of the service registry is to manage, administer service versioning. This allows for quality of service (QoS) based routing of service-based workflows.


3.3 Service Provider

A Service Provider can be an existing (legacy) or a new application. An application itself is conceptually composed of business logic and accompanying data stores.

Service Provider = Application Logic + Data Store

This notion is adopted in order to take advantage of business functionality, which exists currently within the applications infrastructure, thus viewing existing applications as re-usable assets.

The overall emphasis here is to extract the operational interfaces of the application to the underlying functionality (and data) and expose it out to client applications. It is emphasized that the application (and by implication, the business logic contained therein) fronting a database is reused, by exposing it as a service(s). This paradigm is central to legacy application modernization.

Please note that, in general, as a design best practice when building Service Providers, direct access to the database itself (i.e., bypassing the application and security layers) is actively discouraged and avoided wherever possible. The primary reasons for this:

the application’s business logic is not reused

direct access to the database breaks the idea of data encapsulation.

Security layers (originally provided by the above application) are bypassed

There might be mitigating instances where direct access to data is desirable, e.g., for runtime performance reasons, but these are considered exceptions to the rule. Other examples of such exceptional situations include reporting or other business intelligence applications where access to raw data is required; or where the design/platform of an existing application does not permit exposing of functionality easily.


3.4 Service Component

The SOA infrastructure, at its lowest level, is composed of many Service Components, similar to the GOF (Gang of Four) Composite design pattern. Each service component provides a specific piece of functionality within the SOA infrastructure. Examples of service components are:

Existing applications (legacy or as is functionality), exposed as services

New functionality and applications (to be functionality), exposed as services

Thus, the legacy/new applications function as service providers, which then become participatory members in the overall mosaic of the SOA.

SOA Components

3.5 Service Contract

The Service Contract is an abstract interface to the underlying operational application functionality. In pure Web Service terms, it consists of various operations exposed by the Service Component, and can be invoked by an external client. Thus the Service Component is the actual implementation of the contract specified in the Service Component Contract.


3.6 Application Adapter

An Application Adapter accesses the functionality contained within a underlying application or data store by allowing it to be invoked from the Service Component. This allows the functionality to be plugged in into the SOA infrastructure, in the form of reusable services. The Application Adapter handles and encapsulates the details of communicating with the underlying application platform, while providing a standard, easy-to-use API to the client. For example, an ODBC/JDBC connector/adapter to a database or a JCA adapter to a legacy application.

4.0 SOA – A LAYERED APPROACH

The SOA infrastructure weaves, composes, aggregates, and binds unit-level core service components to provide larger, coarser-grained business functionality within a larger, supra context. These supra contexts are arranged in a hierarchical, layered structure within the SOA infrastructure.

The hierarchical, yet layered, approach to the overall SOA stack ensures that there is loose coupling (while retaining high cohesion) between clients and the low-level services. This is to ensure seamless service substitution, an essential attribute of the Quality of Service (QoS) of the SOA without disruption of services in a runtime environment.

There are 3 major layers of the SOA:

Service Component Layer

Business Process Layer

Business Function Layer

4.1 Service Component Layer

The Service component layer forms the lowest level in the SOA stack. It is comprised of service components (functionality exposed as services) and provides the most fine-grained business functionality.

4.2 Business Process Layer

The Business Process Layer, at a higher level than the Service Component layer, provides a relatively coarser-grained interface to business functionality, weaved together by invoking the underlying service components. It introduces the concept of business processes, which are essentially long-running and potentially stateful orchestrations comprising of lower-level service invocations. These business processes and workflows are implemented by BPEL-based modules.

It follows logically that the Service Components can be aggregated and composed to provide coarser grained functionality and map to actual business processes at the domain level within the enterprise. These larger, coarse-grained business functionality components are called Business Process components and are part of the Business Process Layer. They are implemented as BPEL modules, modeling orchestrated and choreographed business processes and workflows.


Note that many Service Components may be invoked within the context of execution of a Business Process. The relationship between Business Processes themselves is very much similar, i.e., a process at a higher level may in turn invoke another Business Process.

Business Process

4.3 Business Function Layer

This layer provides the coarsest grained interfaces to business functionality, and is exposed to the outside world. It represents actual business functionality, i.e., maps almost one-to-one with actual real world business processes and comprises of invocations of the Business Processes and workflow components.

Business Functions represent a level further higher up in abstraction and are composed of orchestrated and choreographed invocations of Business Processes. Hence, they represent the coarsest-grain business functionality at the enterprise level.

Business Function

4.4 Composite Application

Composite applications (mashups) often incorporate orchestration of local application logic to control how the composed services interact with each other to produce the new, derived functionality. A Composite Application thus consists of functionality drawn from several different sources within the SOA, where the sources may be individual Service Components, Business Processes, or Business Functions. Composite Applications allow


for the ability to repurpose parts of applications and data to create virtual applications targeted at specific business requirements in real time. WS-CAF is an OASIS standard for composite applications.

5.0 SOA – THE BIG PICTURE

SOA – The Big Picture

This represents the overarching enterprise view across the domains of the interoperability architecture, with the SOA dovetailing into the overall Enterprise Interoperability vision. It also displays the highly composite nature of the SOA, where a business function may invoke multiple processes and/or workflows, which results in invocation of multiple


lower-level services. The Business Process components and the Business Function components provide the building blocks for assembling more complex, composite applications.

6.0 SOA EVOLUTION

The following diagram shows the overall evolution of the SOA philosophy from a non-SOA infrastructure to SOA-based, distributed computing environment. The emphasis here is to migrate from isolated application silos and stove pipes to SOA comprising of high interoperability between reusable business services.

SOA Evolution


7.0 SOA REALIZATION

The following section outlines the logical progression of steps to be taken in realizing the overall SOA. It provides the bridge between the present as is to the future to be in the organization.

Please note that this is not intended to be a project plan, rather a logical progression of steps to be followed. This model provides a high level work breakdown structure (WBS), based upon which a detailed project implementation plan can be developed.

Further, it is to be noted that these steps are repeated by individual application development processes as they are being built.

SOA Realization – A Conceptual View


7.1 SOA Realization Maturity Model

The SOA is envisioned to be evolutionary in nature, primarily over three distinct, overarching maturity levels:

Maturity Level I: SOA Service Enablement

Maturity Level II: SOA Process Enablement

Maturity Level III: SOA Business Integration and Optimization

SOA Realization: Progressive Capability and Maturity


Note that these levels may (or may not) correspond to the implementation phases of a SOA initiative; instead, they merely emphasize the progressive capability and maturity of the organization in adoption and implementation of the comprehensive SOA strategy.

7.1.1 Maturity Level I: Service Enablement

At this initial level, all existing (legacy) and new functionality is exposed out as services and registered within the SOA infrastructure. The primary tasks at this level are to wrap functionality into services using appropriate standards, and register these services within the Service Registry component of the SOA infrastructure. This level constructs and enhances the SOA Service Component Layer.

Thus the emphasis at this maturity level is on making sure that functionality is readied for integration and interoperability in the following levels.

7.1.2 Maturity Level II: Process Enablement

This level builds upon the earlier service enablement maturity, acquired by building a portfolio of reusable services, conforming to interoperability standards.

The emphasis at this level is on two specific aspects:

Mine the business domain for business processes and workflows, model and construct them using BPEL, and deploy them as executable business processes and functions

Map the business processes and functions to invoke the services constructed in Level I: SOA Service Enablement

Business Process Modeling (BPM) is a primary undertaking at this level, and serves to flush out the detailed automations and business workflows within the domain and constructs, and enhances the SOA Business Process Layer and the SOA Business Function Layer.

7.1.3 Maturity Level III: Business Integration and Optimization

As the SOA infrastructure developed at the previous levels progressively advances in capability and maturity (a la CMM) with time and milestones, the need for reconfiguration of business services according to changing business needs and priorities becomes a major concern. This and other similar concerns are addressed at Level III.

Note that at this point in the evolution of the SOA, functionality reuse and data interoperability have been achieved to a measurable extent. Level III essentially builds upon this, and provides more value-addition in terms of:

Enhanced business process agility

Enhanced QoS

Metering and logging of services

Enhanced management of business policies across the enterprise, etc.


Business Activity Monitoring (BAM)

Other advanced models and policies instituted for effective governance of the SOA applications and infrastructure.

This is also the level at which the synergies developed, established, and institutionalized at the earlier levels between business process modeling and technology implementations are taken advantage of to effectively link IT capabilities and business priorities in a dynamic environment.

7.2 Comparing the SOA Realization Maturity Levels

Maturity Level I is more technology oriented, which involves exploration, use, and implementation of integration technologies, such as the Application Adapter. The emphasis at this level is the packaging of functionality into a portfolio of reusable assets or services.

Maturity Level II and Maturity Level III are heavily oriented towards working with the business users to determine and refine real-world business processes, model and construct them, which ultimately are correlated to, and use the service artifacts of the earlier levels. The emphasis in these levels is the consumability of the reusable services.

These phases, although functionally independent of each other, ultimately heavily influence the SOA infrastructure. For example, in Maturity Level II, when modeling and building a business process, it may be discovered that a new Service Component will have to be built. In that sense, the phases interact with and influence the design of each other as well.

The Review and Refine process is a common critical thread among the three phases, and is carried out in parallel.

.


8.0 INTEGRATED SERVICE-BASED APPLICATION LANDSCAPE

The following section provides a logical layout for the proposed (to be) application landscape. Note that this layout provides the middle-tier of the overall SOA infrastructure. Existing application landscapes consist of isolated domain applications islands with no real-time and logical information sharing between them. This leads to a fragmented, disjoined, ad-hoc sharing of data between entities within the organization, without appropriate data interoperability, integrity and security standards. Most importantly, this leads to a one-to-one data sharing pipeline, where the infrastructure developed for a scenario cannot be reused across other scenarios.

The following diagram displays the layout which uses the proposed SOA infrastructure and its components, which provides the foundation for interoperability standards between the domain applications, regardless of the native platforms they are implemented in.

Proposed Integrated Service-based Application Landscape


9.0 THE “WHY” OF SOA GOVERNANCE

So, after having taken the plunge into an all-out SOA effort, lets assume an organization has created a reasonably successful infrastructure, wrestled with the myriad WS-* specifications and have a functioning service portfolio in place. As time grows by, new worries are cropping up, about the growth and evolution of the service portfolio, and the risk of, well, being a victim of your own success. This following is applicable even if the organization is not as mature, or it is just setting out on the SOA journey.

Any organization needs some kind of governance, primarily, to hedge against change. Since change is constant and all-pervading in today’s business world, all organizations must have the capability to govern themselves. An IT organization is no exception. Furthermore, since SOA purports to bring forth maximum cohesiveness between IT and business, IT is all the more exposed to change, and therefore, the importance of governance in a SOA environment is even more acute.

In general, SOA governance should address the following aspects in an enterprise, across the different phases of the IT lifecycle:

Best practicesChange managementPolicy complianceStandard operating procedures (SOP) & best practicesContingency management and continuity

Governance, in general, has the following goals:1. Effective change management across enterprise, irrespective of whether that change is

triggered by business dynamics, competition or regulatory compliance obligations)2. Minimization of impact of change in a shared service environment3. Ensuring quality of service (QoS)4. Enterprise-wide synchronization of work items in an operational context5. Promote enterprise-wide awareness of processes6. Enforcing policy throughout service lifecycle7. Ensuring overall corporate and business goals are met

Incorporating governance should be an incremental and iterative goal into the enterprise, so as to promote a governance-friendly organizational culture. What is a governance-friendly organizational culture? This usually translates into the adoption of generally accepted business and technology standards and methodologies and adherence to standard operating procedures (SOP), but additionally, that the adopted measures are institutionalized and adhered to. It means that the IT organization is a dynamic setup, which embraces and understands change, and is setup from the get-go to work with change. Such a conducive atmosphere is crucial to ensure easier that subsequent incremental adoptions of the governance model are successful. It has be recognized that there are risks in overdoing or under doing governance. Overdoing governance has the effect of introducing too much bureaucracy into the daily workings, under doing it simply leaves the organization with little control and governance.


10.0 GOVERNANCE ACROSS THE LIFECYCLE - IMPLICATIONS

The SOA lifecycle, and in general, the software development life cycle (SDLC) consists of the following phases:

Inception and ConceptualizationRequirements gathering and definitionAnalysis and DesignConstruction and ImplementationDeployment and TransitionExecution and Monitoring

The diagram below shows the inter-dependence of the life cycle phases, and as is obvious, governance requirements are spread over each of the lifecycle phases, especially because, change can occur at any point in the lifecycle.


10.1 Participation

Effective governance across the enterprise requires effective enterprise-wide participation to ensure compliance.

Business AnalystsArchitecture (Business and Technical)Application DevelopmentIT InfrastructureIT OperationsManagement (Business and Technology)

10.2 Organizational support

One of the better techniques adopted by organizations is to anoint a special working group as the SOA Governance Group, and constituted by representatives drawn from the aforementioned groups. This group effectively serves the following functions:

Acts as the primary stake-holders in effective adoption and implementation of governance.Formulates, designs and audits policies and enforcement rules and guidelinesFormulates, designs and audits change control proceduresIdentifies people, responsibilities and grants authority Change Control Board

o Maintains service versioningo Administers policieso Administers change control procedureso Maintains compliance statistics

Management of runtime parameterso Service availability (for e.g.: heartbeat monitoring thru synthetic requests)o Service usage, metering and load analysiso Service performanceo Service endpoint virtualizationo Transaction monitoring and analysiso Policy enforcement

10.3 Service Ownership and Portfolio Management

Clearly, the question of service ownership needs to be addressed very early on. A major shortcoming of a traditional IT organization is that once deployed, the ownership of an application tends to fall on the IT operational organization. This is myopic because the operational organization lacks an “business” view of the application, and is focused on operational aspects like infrastructure capacity and optimal utilization patterns.

Typically in an SOA, an application (or service) is designed to be reusable by various parties (potentially external partners, as well). In that scenario, the following questions need to be addressed:

Who has the ultimate responsibility to ensure that any change requested by one party does not adversely affect others?


How is the expected quality of service (QoS) and compliance with service level agreement (SLA) obligations maintained and guaranteed? What are the correctional processes and plans to ensure this?

This problem is even more “clear and present” in a large enterprise, especially when various different teams are concurrently developing and deploying service-based applications. These services constitute a “service portfolio” collectively owned by the enterprise, which imposes governance requirements different and unique in nature. The service portfolio is no different from a financial portfolio in the stock market, and needs to be fine-tuned consistently to make sure that maximum return on investment (ROI) is extracted, and the total cost of ownership (TCO) to the enterprise is under control.

10.4 SOA Funding and Project Management

At most IT organizations today, the current practice is to allocate funds for SOA and “service orientation” under existing funding vehicles; and all SOA implementation is expected to be performed under the existing projects, thus leveraging currently ongoing efforts. This is akin to looking at SOA as a “bolt-on” effort. While this may make sense from an accounting perspective, unfortunately, it undermines the very premise of SOA. A “projectized” view of SOA efforts tend to take on a silo-ed, domain-specific perspective, while SOA, by its very definition is more of an across-domain activity. It is acknowledged that the current patterns of funding for SOA initiatives are not expected to change. However, given the current situation, it becomes obvious that service ownership and portfolio management becomes extremely critical. Any shortcomings in that respect will cause the overall SOA efforts to fail.

10.5 Infrastructure & Tooling

Effective governance and automation requires solid infrastructure and tooling support. This includes:

Requirements repositories and toolingDesign, Modeling and Development toolingSource code control toolingTesting toolingDeployment and Configuration Management ToolingProject Management and Reporting ToolingRepositories, Registries and Libraries

Typically, IT organizations tend to procure tooling and pay a lot of attention to the specific capabilities of the tool per se, with little or no thought to the interdependence of these tools. Obviously, unless these tools interact and interoperate with each other, information remains encapsulated within one vertical slice of the tools’ capabilities. So for example, a requirement existing in a requirements repository (created by the requirement tool) needs to be linked, traced and tracked into the design repository (created by the design tool), and further into the software artifacts repository (created by the configuration management tooling), and further into the testing and deployment repositories. It is obvious all of the above tools need to be viewed as integral, constituent parts (cogs-in-the-wheel, if you will) of an over-arching governance framework. They need to interoperate, to provide a complete, dynamic and detailed management picture along with end-to-end traceability in the lifecycle.


11.0 GOVERNANCE IMPLEMENTATION APPROACHESSo, how does an organization adopt and implement SOA governance? There are essentially three approaches.

Green Field - Implement entirely new governance model from scratchMeet-in-the-middle - Utilize existing models and practices, incorporate them and improve upon themAs is - Persist with and document existing governance model and practices

Obviously, very few organizations have the luxury of starting off from the ground up, and so the Green Field approach to governance is not practical. Most organizations have some sort of legacy in terms of policies and best practices, and wish to evolve further, using that legacy as a basis. Therefore, generally, a meet in the middle approach is desirable, since it allows an organization to leverage existing investments in tooling; policies, standards and practices; while affording opportunities to fill in existing gaps and address shortcomings on an overarching “enterprise-wide” basis.

Typically organizations find themselves thinking about governance in parallel with existing SOA-based initiatives. Therefore they implement, essentially, a "build-as-we-go" SOA governance strategy; based upon a continuously, progressively maturing SOA infrastructure. Therefore, implementation of a governance framework to "govern" this SOA strategy also has to be a "build-as-we-go" strategy, in lock-step with an organization’s SOA implementation strategy.

11.1 Addressing disparate frameworks and methodologies

In the foreseeable future, applications (and by implication, "reusable" services) will always be developed by various distributed teams, each with their own favored development methodologies and favorite toolsets. For e.g. one team might favor Rational ReqPro as a requirements repository while another team might favor Lighthouse RM. In another scenario, one team might be Lean enthusiasts, while another team might favor XP. From an SOA perspective, governance has to extend across these teams and their disparate tool sets. This will, inevitably, lead to various different products/platforms/toolsets being used during the specific lifecycle phases of development. These toolsets can include:

o project management and reporting toolso requirements gathering and management tools. o analysis and design toolso source code management toolso automated build and continuous integration toolso issue-tracking toolso testing tools (unit, integration, UAT)o deployment and configuration management toolso runtime tracking and monitoring toolso log management tools

Therefore, it definitely does *not* make any sense, to force upon such a distributed IT organization, a single product/solution/toolset for overall governance. Rather, a solution which


imports/exports information from/to various products/frameworks (for e.g. requirements repositories, SCCM repositories, bug/issue tracking repositories, you get the idea), and yet presents an integrated command & control view of the battlefield (so to speak) would be ideal. This constitutes a federated approach to SOA governance.


SOA Architecture Considerations · Architecture (SOA) and Enterprise Interoperability environment...

Documents

Transcript of SOA Architecture Considerations · Architecture (SOA) and Enterprise Interoperability environment...