Nine common mistakes in SOA
Commonly happened mistake in SOA are the following ones.
- Irrational SOA Exuberance
- Forgetting the Data and Leaving SOA to the “Techies”
- Succumbing to “Not Invented Here” Syndrome and Starting too Big
- Starting in the Wrong Place and Assuming That Everyone Thinks Like You:-
- Choosing Dictatorship to Combat Anarchy
- Underestimating the Technical Issues
- Allowing Un shareable Services to Proliferate
- Excessive Centralization
- Selling SOA Before You’re Ready
1) Irrational SOA Exuberance:-
Transformations are supported by many tools and can be entirely automatic. It may be an easy approach. It is also a poor one. It causes a range of problems. Services are implemented in software. Most pre SOA and components is not meeting the SOA requirement of business design. Objects and components remain integral aspects of software engineering. The designing of SOA style services is conceived separately.
The design of event processing is very different from the design of interaction. The consideration of behavior that is event driven or interactive must be applied when services are being designed.
Action Item: – The independent and dedicated step in the software design life cycle is the design of SOA services. These design services as externally facing the business functions, not as technical software modules.
2) Forgetting the Data and Leaving SOA to the “Techies”:-
Services designed in SOA environments are long term assets. The important principles of normalization of services are different from the normalization of a data model and are its relationship to the underlying data.
Action Item: Strive to design services in a manner that is coordinated with the design model of the services’ underlying database.
SOA to the “Techies”. When evaluating the quality of an SOA design the benefit easily can be missed. Clarity of business semantic content of the service interfaces is essential for cross applications integration, composition or multi enterprise use.
Action Item: SOA design is a shared challenge for the business and IT sides of the enterprise, and organize your SOA practices accordingly. Bring both sides to the “design table,” or risk creating an underpowered and underused SOA environment.
3) Succumbing to “Not Invented Here” Syndrome and Starting too Big :-
One of the most important benefits of SOA is the increased reuse of software. The success of a service can be measured partly by the degree to which it is reused by outside application. Where the external solutions are understood and used the IT environment must develop a culture. Challenges of Succumbing to “Not Invented Here” Syndrome are the following.
a) Difficult to design: – It is difficult to design interfaces to address external requirements that the applications original designers weren’t prepared to support.
b) Reused:-Not every application has internal information resources that are of general-enough interest to be reused.
c) Different characteristics: – The security, integrity and performance characteristics of different applications vary, and mismatches can block reuse.
Action item: – Reward the reuse of software designed by others. Foster a technical and cultural environment where such reuse is considered a characteristic of excellence in software engineering and preferable to custom programming.
SOA is stating too big. The enterprises that they are late in using SOA tend to leap from SOA skepticism and a wait-and-see strategy into a sudden, strategic commitment. Budgets suddenly are available. Its results are awaited eagerly. The IT organization often is encouraged to start thinking large scale.
Action Item: The starting too big can lead to big mistakes. Think strategically, but act tactically. Develop a long-term vision for SOA, but implement it incrementally, learning during the process and managing the risks of transition.
4) Starting in the Wrong Place and Assuming That Everyone Thinks Like You:-
In SOA the question of where in the business cycle to begin designing services is a critical one in SOA. In some cases you can design a set of services around business models and data models. The business model can be used to link the business analysis of the application with its software implementation.
Action Item: – Attempting to take a shortcut to opportunistic quickly created and soon discarded services, invest in systematically designed sets of fundamental core services as the initial stage of design, allowing for rapid opportunistic extensions later.
Assuming That Everyone Thinks Like You. An SOA initiative is a long-term endeavor. Its success measured based on multiple criteria and schedules. It has become a subject of interest beyond the programming community.
Action Item: Manage the expectations of SOA investments by understanding that the involved parties don’t all envision the same outcome as the objective. Consider these differences in tailoring business communications at all levels.
5) Choosing Dictatorship to Combat Anarchy:-
Individual it projects, groups, divisions and domains have hunger for independence. SOA benefits that can achieve by an isolated project or department are limited. The larger the scope of a coordinated SOA effort, is the greater the potential benefits of the following ones. They are
a) Increased agility
c) Sharing of resources.
Action Item: – The centre of coordination establishes a COE among SOA project. It recognizes the realities of individual projects and ensures that its directives are minimally intrusive.
6) Underestimating the Technical Issues :-
SOA are more challenging than vendors would like users to believe. For most large Organizations by provide a universally accepted standard foundation. Web services play a technology role only for the SOA backplane. Within and beyond the boundaries of the enterprise
Eg: – business-to-business integration
Using integration devices service implementations also must be carved out of pre-SOA applications.
Eg: – Adapters, programmatic integration servers or other forms of integration middleware.
Service consumer applications must be deployed on platforms that support multiple devices and presentation styles
Action Item:- Only for small-scale, experimental SOA projects use point-to-point Web services connections
7) Allowing Un shareable Services to Proliferate
SOA environment minimizes the number of services needed to support consumer applications. A typical SOA goal is maximizing the number of shareable services. Shareable services yield the below things.
a) Faster development or integration of consumer applications
b) Lower development costs
c) Easier maintenance. Organizations shouldn’t expect 100% of their services. It is shared across more than one application.
Eg: – Some services provide functionality that is unique to one application.
SOA support the service definition phase by a formal process
Eg: – Business analysts, architects, developers and integration specialists.
The goal is to ensure that a service meets the broadest possible of requirements. These process is costly and lengthy.
Action item:- Assign responsibility for “chasing” new, reusable and shareable services is to maximize the reuse and sharing of services, enforce a formal services definition and validation process, implement a design-time service registry, create incentives for service reuse and sharing.
8) Excessive Centralization:-
SOA initiative is a Herculean effort. It is because of the several political, organizational and technical issues to tackle.
Eg: – On the basis of different technology platforms, business units or subsidiaries already may have implemented their SOA backplanes.
Different business units may have different characteristics. They are
c) Protocol support requirements for their SOA backplanes
Each domain is managed by one business owner and by one technical manager. Domains are federated through an enterprise SOA backplane and registry. The enterprise SOA backplane is an infrastructure. The enterprise SOA backplane and registry are managed by a central SOA.
Action Item: – To overcome political, organizational and technical hurdles you have a large organization with semiautonomous business units and subsidiaries, then consider using the federated approach to SOA.
9) Selling SOA Before You’re Ready:-
In technology or sophisticated skills small-scale, experimental SOA projects don’t require huge investments. By adjacent application areas and larger developer communities the success of these initial projects often stimulates SOA adoption. At the CIO levels OA continues to be perceived as a specific approach adopted by a circumscribed set of projects. SOA probably is beyond the empowerment level of most CIOs. It requires the CEO’s or even board-level support. SOA can be dangerous to seeking top management’s commitment to enterprise wide.
Action item: – Action Item:
SOA recently avoid pursuing enterprise wide SOA initiatives. It focuses post-introduction efforts on smaller-scope initiatives, such as intra domain or business-unit-wide projects.
- SOA Tutorial
- SOA Requirements
- SOA Tutorials in IBM site
- Introduction – When should SOA be used
- Entry points to SOA
- SOA interview questions
- SOA Governance
- Defining SOA
- Basic Components of SOA
- Service Contract and Service Proxy
- Enterprise Service Bus
- Service composition
- Service Repository
- Service Transactions
- Service Reuse
- SOA Testing
- Ten things to know about SOA
- Nine common mistakes in SOA