Section 11.2. The Personal Perspective

11.2. The Personal Perspective

It should not be surprising that it is insufficient for an enterprise architecture such as an SOA "just" to be beneficial to the enterprise in order to become a success. In practice, you must also convince the individual stakeholders to support the SOA. More importantly, you must enlist the key decision makers and domain experts.

An SOA certainly can provide tremendous advantages for the individual people involved in the enterprise architecture. This section provides the most important arguments for an SOA from the perspective of the different roles in an enterprise. This information will help you "sell," the SOA to each individual in an organization, adopting each individual's role and accommodating personal requirements. In particular, we consider the following roles:

• CEO

• CIO (department for IT strategy)

• Architect

• Project Manager

• Functional department

• Developer

• Vendor of standard software (sales or product management)

Table 11-1. CEO

Benefits

Challenges

Agile Strategy SOA helps businesses better react to environments. IT does not limit business strategy, but instead enhances it. Short-Term Planning The planning horizon can be reduced drastically because SOA enables step-by-step approaches. Budget Reduction The budget allocated to the IT department for pure maintenance tasks can be reduced and is, thus, freed for business-oriented development projects. Technology and Vendor Independence The dependency of business functionality on the technological infrastructure is reduced significantly as is dependence on software vendors.

Make It Happen Introducing an SOA means change. It inevitably requires coping with some resistance. A clear strategy and firm commitment are needed to overcome this resistance. Initial Overhead In its initial phase, the introduction of an SOA creates overhead, for which it is important to allocate a sufficient budget. ROI Consideration The benefit of the SOA must be quantified. Reporting Reporting to the board is a possible requirement.

Table 11-2. CIO

Benefits

Challenges

Independence from Technology The dependency on the underlying technology is reduced and planning can be focused on business requirements. Positive Role of IT Department With an SOA the IT department can take the role of an enabler. Usually, the introduction of an SOA moves the IT department closer to the business units. Cost-Reduction The CIO often has a cost-reduction target agreement. Increase of Influence SOA enables the CIO to participate in the decision process regarding the architecture. Manageable Project Size An SOA enables small projects and step-by-step development.

Migration to SOA The existing IT infrastructure has to be migrated towards an SOA. Decoupling Existing functionality has to be decoupled and made available as services. This is far from trivial. Change of Attitude Usually, a change of attitude is required within the IT department when changing to a service-oriented approach. Members of the IT department must be convinced that an SOA is beneficial for the enterprise as a whole and for them as individuals. Change of Relationships Usually, relationships to suppliers of standard software and infrastructure solution must be reconsidered.

Table 11-3. Architect

Benefits

Challenges

More Attractive Job An SOA allows the architect to focus on more interesting tasks. Disentanglement An SOA frees the architect from the entanglement typical in monolithic IT infrastructures. This limits the scope of architectural decisions and changes them to become more manageable. Loose Coupling Architecture specification is simplified as the degree of coupling is reduced significantly. Code Reuse Implemented functionality can be reused and need not be coded over and over again.

SOA Adherence Architects have to establish structures and processes ensuring SOA adherence. Reuse Architects have to make sure that services are designed with reuse in mind to fully leverage the potential of a SOA. Open-Minded The architect must be open-minded to amend and change the SOA itself if needed. Missing Technical Standards The technical standardization of SOA-related technologies is not yet complete.

Table 11-4. Project Manager

Benefits

Challenges

Smaller and Shorter Projects Projects become smaller and shorter and are, therefore, easier to manage. Technology Independence Projects are less dependent on the underlying IT infrastructurei.e., planning can focus on the functional aspects of the project. Parallel Development Fixed service interfaces help to decouple development and allow for parallel development. Reduced Project Risk Due to project size and limited technology dependency, project risk is reduced significantly. Easier Testing and Integration The resources necessary for testing and integration are reduced because of decoupling.

Service-Orientation Adherence of developers to the serviceoriented approach must be ensured. Potential Overhead Reusability must be taken into account in the design process. Sufficient budget should be allocated to cover the potential overhead this creates.

Table 11-5. Functional Department

Benefits	Challenges
Independence from Technology Dependency on the underlying IT infrastructure is reduced so that business departments can focus on functional requirements. Shorter Time to Market Business departments can achieve a shorter time to market for new functionality. Reduction of Development Costs The costs for developing new functionality are significantly reduced.	Service Orientation Business functionality has to be made available as services. Service contracts must be fixed and adhered to. Reuse Implemented services must be designed with reuse in mind. This creates some overhead. Sharing of Responsibilities Potential service users must be involved in the design process and will have influence on the service design.

Table 11-6. Software Developer

Benefits

Challenges

More Attractive Jobs An SOA allows the developer to focus on more interesting tasks. Reduction of Dependency An SOA reduces dependencies. Within a single service, developers can change implementations without affecting external functionality. Rapid Prototyping Once a substantial number of services are available, developers can easily test approaches. Better Defined Requirements The interface driven SOA-based development process provides the developers with better-defined requirements. Simplified Testing Decoupling and service interfaces simplify distributed testing.

Respect Service Interfaces Developers have to adopt a service-oriented approach. Service interfaces must be respected. This in turn requires a clear specification before coding. Processes Developers have to accept rigid processes. Shared Responsibility In particular for well-established developers it might be a major change in responsibility for an application because it must be shared between different development teams. Learning New Skills Developers have to learn new skills regarding the specifics of SOAs. This includes, for example, the handling of distributed transactions or the assignment of the ownership of data.

Table 11-7. Vendor of Standard Software

Benefits

Challenges

Sell Components SOA opens up a new market segment for standard software packages. Domain specific services can become a great market. Reduced Integration Costs Unlike contemporary software packages SOA components do not require high integration costs on the customer side. Due to the lower project costs and risks, it becomes much easier to sell such components. Low Entry Barrier Regarding the limited scope of a single service it becomes much easier to create sellable standard software components. Provide Future Proof Solution Customers are increasingly demanding SOA-compliant products.

Customer More Independent A core characteristic of SOA is that it disentangles dependencies and makes enterprises independent of specific components or technologies. Limited Secondary Business SOAs are not well suited to generate much secondary business around standard components. Integration and migration efforts are particularly low. Missing Technical Standards The technical standardization of SOA technologies is not yet complete.