Some of the key considerations in supporting an SOA infrastructure ( read that as an Enterprise Infrastructure) based on our experiences in providing such services to our customers are described below. These are based on an EAI installation serving as the backbone for the service access and deal with issues such as Provisioning, Production support, Infrastructure support, and Socializing new services etc., Of course these are subjective in nature and your mileage can and should vary.
1. Our experience has been that new services are modeled by the Enterprise Architecture Group and their usage standards are also established and published by them. This is especially true for the top down approach towards Service Orientation. Where departmental initiatives (inflight projects) have already gone ahead we expect some of their key stakeholders ( from their development teams) to participate in the Enterprise Architecture groups which are responsible for the modeling activity. This ties in well with the Governance aspects as well, as the current and future usage modeling is related to effective Governance of the Services. At one of our health care customers for example, there are Enterprise Architecture Groups whose sole responsiblity was to define collaborations and interactions between enterprise applications. From the nature of these collaborations it is difficult for any other group ( besides the Central Architecture Group ) to enforce any type of standards, usage modeling or otherwise.
2. Agent Updates fall under the category of normal software update distributions, and is normally done by the Centralized Infrastructure Group who are already doing other software updates. However any code level changes to the Agent infrastructure will not be done by them: they just focus on the distribution aspects. For code level changes it is a toss up between the Departmental Groups and the Enterprise EAI Competency center. At one of our large Financial Services customers, it is the centralized EAI group that does the software changes to the agents. This is because Agents fall under the category of middleware. The only time when the Departmental Groups get involved in this activity is during the course of an inflight project. But this is a transitory state which can and shoule be quickly remedied.
3. From a provisioning perspective, a federated structure does exist in some of our client sites, especially the ones that have large and geographically distributed locations. Since Provisioning is an activity that has direct impact on the LOB operation it made sense in the above situation to have a federated provisioning agency. However the best practice here is to just let these federated groups to focus on provisioning activities alone without also getting into the change control activities related to Agent updates etc., (refer to Answer 2 above). Middleware change management is still a centralized activity with departmental participation.
4. This activity involves the following sub-activities, normally:
Socializing: This is the initial step which has to be done iteratively as new services are added to the portfolio. This obviously is an activity of the Central Architecture Group (perhaps the EAI Competency Center) and this is how it is typically done in organizations like the above mentioned health care client. This is a key activity and has to be done effectively to prevent the proliferation and duplication of services across the enterprise. The key problem which our client organizations are facing is the Not Invented Here Syndrome wherein Departmental development groups are loath to accept a framework or component developed outside of their immediate groups. The key mitigation strategy to address the NIH syndrome has been to co-opt the key leaders of the development groups into the Enterprise Competency centers and sell the service concepts to them and then utilize their local influence in driving acceptance across the departmental groups in the enterprise.
Reference Implementation: Once the socializing has been done, providing a robust and non-trivial reference implementation is a key success factor. The reference implementation should be accompanied by well documented source code, API Documentation, Packaging and Deployment instructions, and a good set of test scenarios and test cases. This shall avoid the prescriptive approach which development teams normally dislike and provides them with a way to do a test run of the service without fully commiting to it.
Installation Support: If the RI above is acceptable and is adopted by the Departmental Groups, then Installation support becomes a key issue. This involves the Federated Provisioning Groups referred to above and they can provide the localized and personalized care and feed required for deploying the service access. This might be as simple as providing access information to a centralized service and ensuring that the right Registries are accessed by client code, or as complex as installing local hardware and software to provide a federated structure to the service.
Production Support: On an ongoing basis the Service users must have the needed Production Support because there could be change management activities going on with associated changes to service interfaces. Organizational impact analysis related to service interface changes can be a very effort intensive activity and this should and is adopted as part of Production Support activity by some of our clients.
5. The Production Support mentioned above encompasses the key activity of Error handling and in most of our client sites, this first goes through the traditional process of triaging. Different support groups get involved after the Production problem gets into the Support management infrastructure ( such as a Remedy installation, for example) and then a well defined traiging process is followed. If this process of analysis reveals that the issue is related to a Service implementation then the Support group for that Service is given the responsibility of fixing it. This could again have a middleware orientation or an application logic orientation and depending on this second level teams in the EAI Competency Center or the Application group will get involved. This is actually a federated triaging structure in which multiple rounds of analysis is done to isolate the group responsible for the fixing the Support issue.
