For example, they have developed a tax engine for commerce tools and billing applications. The systems have been upgraded to avoid the common problem (causing much lost time and money for both the enterprise and its customers) that invoices didn’t match bills because the systems were built separately and viewed the outcome of the same process differently. The IT department used SOMA (Service Oriented Modeling Analysis) to help the parties decide. This method recommends a set of existing and/or new services to build and reuse.
“The trick,” he notes, “is to get the value to be gained out in front of a wide array of stakeholders so that they will recognize that their group needs and will use that function/subsystem/system, too.” That builds support and can avoid the difficulty of getting multiple groups to assign budget funds toward a cross-enterprise project.
Another SOA implementation in this enterprise is an order validation service. Two different departments were looking to build such services to different sets of requirements. If no one had reviewed the project at an enterprise level, no one would have seen that they were nearly the same. — What was needed was one common service that checked for everything. IT was the facilitator that enabled the review and agreement on a single, common service, saving resources and avoiding duplication.
Reinforcing the idea that SOA is a process, not a project, our architect offered this advice, “We started with one project. We inventoried the other projects in that area, and we built it up over time. It doesn’t all get done at once; it’s a lengthy process based on projects we’re investing in anyway.”
He offers a few thoughts about how to proceed:
It’s important to build new skills to help overcome the investment hurdle. new model becomes faster and less costly with in-house skills.
Building to the
Deciding how you’ll measure the business value of SOA applications will make it easier to gain approval. It might be ROI, cost reduction, new revenue opportunities, increased customer satisfaction, but deciding what it is and how you’ll measure it will prove important.
Lastly, the architect looked back on his SOA experiences and noted a conundrum: He likes the idea of transforming legacy applications by pulling out some pieces from a big application and rewriting them to transform its life, improve performance, or improve code quality without waiting a long time or doing a large migration. But he admits that if you do a good job you will still have the legacy application in place – and since it’s been improved, it will take even longer to justify its replacement.
Extending IT Governance to SOA Governance in a Government Agency
In a Canadian government agency, SOA has been selected as the architectural style and development strategy going forward. Under a newly hired enterprise architect, the decision was made to start with governance. This was made easier because substantial IT Governance useful to SOA (Application Acceptance Standards, Review Standards) were already in place and some pieces of SOA Governance have been put added (BPM Standards, Metadata Repository). They have also added a business oriented governance structure, made up of area directors.
IT reviews new projects and tries to get them to use SOA techniques, starting with BPM (Business Process M). This helps drive reuse and other parts of SOA. These might be within the individual business areas (with some consideration for being able to reuse services written for such solutions) or across the organization. One broadly implemented application is the corporate
October 18, 2006