This project was a combination of enhancements and refinements to existing systems (one of the reasons it could be completed more quickly).
A much bigger project is a major Supply Chain Management overhaul, based on an analysis and modeling of Business Process Management, (BPM). This project was started by IT and included the business groups. It used a popular Japanese business practice – nimowashi – which socializes people into a concept before they meet to discuss it. (Think of it as a consensus building exercise.) This project is scheduled to start in the second quarter of 2007 and is currently in the planning stage.
Another project is being considered which might actually occur sooner than the big Supply Chain Management one. It involves working with a purchased application with a predefined API. The SOA team is starting to talk with the business group now to evaluate whether it has a high yield of reusable services – an important measure of priority at this stage of SOA growth for this organization. A proof of concept might be built in late 2006. The firm looks at this as a seven to eight year project.
SOA Governance was a necessary component of SOA projects at this firm right from the beginning. Their business exists in silos, e.g., vehicles, customers, and parts, and each business group has its own interests, priorities, and budgets. Governance was required for prioritization, to decide who and how the firm would use SOA.
On the other hand, they don’t believe they have SOA Governance fully in place yet. They view themselves as developing it with IBM, employing IBM best practices and fitting them into their own business process. They have not fully deployed SOA Governance and they don’t have all of the staff and governance pieces in place yet.
SOA Governance is separate from IT Governance, but it’s definitely linked. While IT initiated SOA Governance, the business units are expected to be more involved as the use of SOA grows. The organization believes strongly that SOA Governance will allow the firm to be more agile and responsive. They already use IT Governance. In the new projects even at this early stage of SOA, they already identified dependencies in vehicles which required SOA Governance.
They anticipate implementing all of their SOA projects under SOA Governance, although they admit this will be an organizational challenge; individual business units are not accustomed to this brake on autonomy. On the other hand, their tradition of Keizen – constant improvement – will provide feedback into the governance stream and ensure its ongoing refinement.
Full Steam Ahead in a Tier One Technology Provider
The Vice President of Enterprise Integration Architecture we interviewed got right to the point. Reiterating something we heard from several customers, he said, “We had to look across the whole company to fix the whole problem.” That’s the difference between just implementing SOA as a new kind of technology perspective in answer to a particular business problem (generally within a particular business department, location, or division) and implementing SOA with Governance, enforcing an enterprise-wide view.
For this firm, although SOA Governance started as a separate project, as part of Web Services and then grew with it into SOA, it was off on the side, different than IT Governance. But as it grew, it became more mature and widespread; the overlaps with IT Governance became more obvious. This architect believes many customers will integrate SOA Governance and IT Governance, perhaps from the start, perhaps over time.
The enterprise is doing many SOA projects, trying to set the example for its customers as well as serve its own business interests with the best available technology concepts.
October 18, 2006