It is essential to codify domain semantics in the analysis phase of the project. It is a natural outgrowth of business domain analysis and reengineering. If you employed a tool to do your IT asset mining, it will likely be able to help your team collaborate on semantics as well. The end result will be both a collective understanding of semantics, as well as associated vocabularies expressed in terms of XML schemas, WS-Policy, and XACML policies (which depend on data semantics and vocabularies), as well as other standardized formats. Transforms and composition points needed to support reuse and integration will fall out of this exercise along with associated infrastructure requirements.

Depending on your industry, you may be urged to adopt a canonical data format from an industry standards body. This is a good way to seed the semantics development process, but it will likely not get you all the way there. For one thing, it might not jibe with your existing enterprise data model. It is much more important that your semantics fit your business domain and that your team understands it implicitly. As such, a modified form of the standard form can be used. You can always transform data at the perimeter to a standard form to support federation as needed and capture such infrastructure requirements.

Focus on the Service Consumers
How new services are called and used by consumers must be well understood before SOA enablement can ensue. Consumers include user interface clients as well as internal and external service federation participants. New services and a transformed business will undoubtedly cause some impedance mismatches with consumers as they adapt. New consumers may ultimately be constructed, such as new user interfaces.

Traditionally, user interface clients suffer from a great deal of "hackitis" in big applications. It is very common for business rules and policies to be either hard-coded or trapped in a portal repository. This causes a twofold problem for en masse SOA. First, we would like to limit the number of rules and policy repositories that need to be managed. Large enterprises can have many portals, for example, and it would be quite counterproductive to manage rules and policies for each, especially in an environment where agility is the goal. Second and more generally, if consuming new services at the UI consists of potentially painful changes to backing code, hope of enterprise agility is lost. At the end of the day, it's the service consumers that present the services to the customers, partners, etc., and deliver the business value we are working so hard to create. It will likely be necessary to create infrastructure elements to support transition-of-service consumers to the new SOA. A clear understanding of the roadmap for these consumers to move to the SOA should be created, and infrastructure requirements is needed to support the roadmap captured. In the design/build/test phase (Part 2 of this series) I will also detail some portal design patterns that leverage the SOA infrastructure to drive agility in the UI tier while enabling central administration of business rules and policies. Even though it is usually pretty ugly, paint a picture of your service consumers' ability to interact with the emerging SOA.

Connect the Dots
Having defined the business flows/services (top-down approach), existing enterprise assets that will be repurposed for SOA (bottom-up approach), and the data and metadata semantics that drive service interactions, there comes a time to connect the dots and perform a gap analysis to determine a roadmap for design. IBM SOMA suggests performing "goal-service modeling" to complete the services set and prioritize services against specific business goals. Swimlane modeling can also be performed against all business flows, in priority order, to further this prioritization. This will reveal dependencies on micro services, components, and infrastructure elements such as transformation, mediation, and policy enforcement. By way of example, business analysts for a brokerage may place extremely high value on a new customer net asset value calculation. Such a composite service might include data from two internal domains - customer account and financial advisor management - as well as an external source in the form of a stock quote Web service. The process flow might be to gather all customer account data, for all clients of an advisor, compose the data into a higher-order domain entity (Advisor Customers), and calculate a net asset value for each customer based on data from the stock quote service. In this case, two internal data domains, one external service, and SOA infrastructure elements, including transformation, composition, and security policy administration and enforcement, will be involved. As such, an infrastructure design roadmap would include these elements at the beginning of the design process. In this way, the infrastructure requirements set can be made to include a prioritization of elements that will maximize business value with respect to development time.

Develop a System Change Taxonomy
Perhaps the most difficult aspect of en masse SOA analysis to get at is the development of a system change taxonomy; a classification of what has to change in the system, and how fast, to support the business agility vision. A major element of infrastructure design will be to create facilities for metadata change management, i.e., rules, policies, service contracts, service compositions, transforms, etc. Without a specific classification and prioritization of system change, effective design for change is not achievable. The infrastructure requirements set must capture this as completely as possible. Some metadata change requirements will be obvious, like service compositions, while others will be less so, such as changes of all the types of business rules in the enterprise. Care must be taken to expose dependencies between metadata under threat of change, e.g., schema changes that impact policy resource expressions defined in XPath. Create as detailed of a classification (and sub-classifications if need be) of changes in your system as you possibly can and codify it in the infrastructure requirements set. Don't forget to include aspects that may not even exist in your current enterprise, e.g., fine-grained access control policies, federation policies, and compliance policies. Development of metadata change facilities and repository management will be a key infrastructure design step.

En Masse SOA Analysis Is Iterative, Expansive, and Time Consuming
En masse SOA analysis may well begin with a very small team, even for a large enterprise. Broad goals may be painted at first without much specificity at all. Analysis artifacts such as business process flows, policies, and IT assets are derived by iterating through the activities that create them, dividing the problem domain further with each pass and including new team members as needed. At some point in the process, it will become apparent which infrastructure elements are likely needed to support the system. At this point the infrastructure design process can begin and join the analysis iterations. As the infrastructure design becomes apparent, service and application design can also join the iterations. When final requirements are signed off, system design can complete and implementation can begin.

Summary
2006 has been a year in which some enterprises are launching en masse SOA enablement efforts in an attempt to engender efficiency in their IT operations and achieve competitive advantage through agile business process management. As such, this article attempts to distill an en masse SOA enablement analysis method as an adjunct to well-known service development methodologies, as well as by keeping the method true to the divide and conquer precept of SOA. The goal of seeding an infrastructure design process with an infrastructure requirements set was espoused. Emphasis was placed on getting the vision of agility set and recasting the business domain in its light. It was then advised to elicit infrastructure requirements through the processes of mining for IT assets, developing domain semantics, focusing on service consumer channels, and creating a system change taxonomy. Prioritization of infrastructure design elements can be elicited when the dots are connected between the future state vision of the business and existing IT assets. An iterative process of analysis was espoused that seeds an iterative design process. Part 2 of this series will focus on the design/build/test aspects of the methodology.