Blog RSS address moved
Wednesday, April 11th, 2007Just fyi, if you’re subscribed to my blog RSS feed, the address is now:
http://www4.sungard.com/blogs/darrenWesemann/feed/
Archive for the 'General' Category
The Registry is Important, but there’s much more
Friday, November 17th, 2006For SunGard, it was an amazing effort to catalog our software assets, due to the mere size of our offerings, (although this effort is never really done, as decomposition is an ongoing effort). I mentioned in an analyst interview last week several initiatives that are just as important to initiate as a Registry. Here are some of them:
1. A central and tangible place to test, certify, integrate is crucial. Recently, we announced a test lab initiative we’re simply referring to as Center of Excellence. (The press release can be viewed at: http://sungard.com/journalists/global/sungard_launches_center_of_excellence
_for_common_services_initiative.htm)
The CoE ensures that operation of the production environment (which is a separate environment) is hardened, and provides integrity to deployed solutions.
2. Specifications that can be read by business people are necessary. A document written at a business level ensures that people throughout the organization can understand the value of each service within their own context (which is very important in composite solution orchestration, because a new context provides opportunities for additional services to be consumed, thus adding more value).
3. Provide for Orchestration. When a service is registered and available for consumption, combinations of services will be used to achieve higher levels of functionality (composite solutions). The configuration of solutions via combining individual services requires an Orchestration approach involving a tool, which deals with issues that involve concerns beyond merely making a call and getting a response. Services may need to ensure an order in a process flow is guaranteed are great candidates for composite solutions, and an orchestration tool enables that. Recently, SunGard acquired an amazing BPM tool that facilitates orchestration with a tremendous amount of power and flexibility. The tool (Carnot) is now a key fixture in the CSA’s utility stack, covering the orchestration capability. (The press release can be found at: http://sungard.com/journalists/global/sungard-acquires-carnot-ag.html.htm)
5. Beyond orchestration, there is a service contract, business definitions, and the usual enterprise functions of operations, security and traceability. Some companies rely on Web Services (WSDL and SOAP) as their service implementation. SunGard, due to the market we serve, embraces other service protocols as well (FIX, SWIFT, etc.) as Web Services don’t cover all services. Beyond other service protocols and interfaces, there is data mapping, and the enterprise operational aspects of deploying and running services in production.
In closing, I came back to the Registry itself. The Registry is far more than a simple catalog of assets. Because of this, we don’t use a UDDI-style registry, as the amount of information needed to be stored about each service, and queried against simply goes far beyond the UDDI capacities. There needs to be certification, contracts, documents, attributes, characteristics, (all the issues discussed above) wither within the Registry or accessible to the Registry. So, I guess it really is all about the Registry at the end of the day, just lots of relationships to it.
Collaborative SOA Lessons Learned
Monday, September 4th, 2006Last week I spoke at the Gartner Financial Services Summit in Boston on the topic of Best Practices for Enabling SOA Composite Solutions for Financial Services. I used as my primary theme, 7 lessons learned in SunGard’s collaborative SOA effort. I think the term “Composite Solution” has a comprehensive meaning for this subject. In my opinion, any SOA effort should yield a Composite Solution (independent parts or systems working together to provide greater value). Composite Solutions will be required more and more by the businesses we work for, as they continue to ask for more integration, (reasons include: regulatory compliance, B2B collaboration., mergers/acquisitions, deploy new packaged applications, single view of customer, implement self-service portals, improve data quality, etc.). Additionally, successful collaborative SOA’s involve much more that simply sharing data and services, or procuring a particular vendor’s SOA stack. I’ll attempt to lay out 7 things we found particularly important.
Lesson #1: Governance process is more important than technology
Clearly the most important aspect of our effort is the very collaborative process that provides key centralized support, involvement of every area of the company (both business and technical). The central team is dedicated to the governance of common requirements, standards and technologies, offers guidance and education, manages the common code base and infrastructure, provides support services, facilitates communication and collaboration and administers automation for builds, tests and deployments. Our process provides for key collaborators within each Business Unit (Common Architects for technical representation and Common Product Managers for business representation). On a regular basis, cross-company collaboration occurs with weekly discussions, workgroups (subsets) define proposals, and the key collaborators vote on adoption. The collaborative process depends on common and centralized documentation, code, issue tracking, and on-line forums.
#2 Lesson Learned: Ensure key stakeholders from each domain are engaged
Probably the most continually challenging aspect of our effort is identifying key business stakeholders and ensuring they are engaged. Business stakeholders need to define which topics are important to collaborate on from a business perspective, assign members of their teams to participate in collaborative discussions and they need to be measured for participation and value added, with incentives provided.
#3 Lesson Learned: Measure and report on key metrics
In line with the old adage that you can’t improve anything you don’t measure, this lesson is key to the continual increase in value in any collaborative process. The kinds of things we found useful to measure include: contributions, consumptions, participation in collaborative workgroups, responding to common communications, cost savings and cost spend on collaborative activities (there is after all overhead to collaboration), revenue, and time savings.
#4 Lesson Learned: Inventory all assets in a directory or catalog
Likely the most important central repository is an asset catalog, or component registry. The registry should identify useful decomposed parts of legacy applications as well as the new stuff. Services, interfaces and components should be identified. Too many limit their registries to Web Services… keep in mind there are many interface types to useful components. In the Financial Services industry we have things like FIX, and a myriad of other protocols/interfaces to invoke a service or component. Your SOA is only as good as your metadata. Also, keep in mind version control for the registered assets is critical. You may run into people (as we did and do) that complain that your asset repository lacks something. Your repository should expand through contribution, and if functionality is needed, teams should build it and contribute it, so the next time a team needs the same thing, it is there, in other words if it is not there, it’s an opportunity to add it. Emphasis should be placed on reducing replication and foster reuse, and proposals for major modifications should be drafted and voted on by the collaborative community. A feedback process should identify if the proposed solution is inadequate, or something better exists and the collaborative stakeholders exist to discuss and decide on the best approach. Participation and feedback is crucial
#5 Lesson Learned: Adoption requires a maturity model
A maturity model is necessary if any technology exists in your enterprise at all, (in other words, a maturity model is always necessary). I’ve described our maturity model several times in my blog, so I won’t re-do that here, instead I’ll merely highlight the benefits of each level of the SunGard maturity model for reference:
Level 1 – Rapid Service Orchestration
Your application services can be leveraged by other business units quickly and easily, opening up new avenues for growth.
Level 2 – UI Conformity
Bundled solutions can avoid the fragmented user experience that has plagued past efforts at selling “integrated” solutions
Level 3 – Improved Processing
A single database provides deeper integration for better processing and analytical capabilities
Level 4 – Architectural Guidance “out-of-the-box”
Focus on your business problems, not technology issues.
Develop more rapid solutions by leveraging what already exists
“Out-of-the-box” composite solutions, already integrated
#6 Lesson Learned: Build integrity into the process and technology architecture
Key to any process is trust in the standards, reference and process. This is a lesson we continually try to improve, and dare I say… struggle with at times (hey, I’m a practical software guy). Areas of focus for us relative to ensuring integrity is built in are: automated testing, unit tests, functional tests, scale or stress tests, peer reviews, profiling, documentation, and standards.
#7 Lesson Learned: Harvest the low hanging fruit first
Uncover the projects underway that require integration, work with key business requirements, and identify real needs, ensure key stake holders are driving the projects, and above all… start small! Get some early successes.
