Standardizing on a portal architecture also enables portlets to be created and governed right alongside the business services they surface. For example, if a bank has a business service that returns a customer's account history, the portlet that does the actual display should be created and governed right alongside. Portlet preferences can be used to tailor the display characteristics, e.g., which ledger columns to display, and also for inter-portlet communication, e.g., which account to display. Under such a scenario user interface design and management becomes an order of magnitude less complex and costly. To achieve this end, the SOA infrastructure (and associated portal infrastructure) must be designed with these facilities in mind.

Generate a Detailed Design
There will come a point when it's time to move from the preliminary design choices to a detailed infrastructure design that may codify one of the preliminary choices or may actually be a hybrid of more than once choice. In either case, it's the detailed design that communicates the future-state of the infrastructure. It's the future-state infrastructure specification that will be coupled with the service development and governance plan to form the totality of the future-state architecture specification for the new SOA enterprise.

It goes without saying that the detailed design should have as much detail as possible, but it particularly needs to have additional views of the infrastructure that communicate to every role in the enterprise what the new architecture will mean to them. Operations teams, security administrators, business admins, and solution architects all need their own views. And the technology selection process needs to start at this time. We'll see next how a process of technology validation should feedback and finish this specification. Feel free to use the tried/true bake-off due diligence process to this end. Also, a roadmap needs to be developed based on prioritization of business needs specified in the infrastructure requirements set. The roadmap details individual projects that must be completed, and in what order, to achieve the quickest and most comprehensive solution to the business case. Leverage the SDC to communicate and collaborate on these final design aspects with the broad team, most notably the business and technical owners of the project.

Build, Test, and Validate
The design of any system is nothing without the validation that comes from a well-conceived build-and-test cycle, and certainly SOA infrastructure development is no different. Build and test should begin as soon as the detailed design stage has begun to specify technology choices. Start by setting up a single test environment and begin to add new components as they are specified. Infrastructure testing is paramount in SOA since so much of the system's functionality is derived from the infrastructure. Write as many test cases as possible, leveraging realistic test services and infrastructure components to validate technology and design choices with respect to performance, quality of service, and ease-of-use assumptions. Feed the results back to the detailed design process to assist with technology selection. Next, begin the process of building a production environment. The test cases already written should form the basis of a production monitoring and testing regime. Detail test cases in the SDC and publish results where they can provide closed-loop feedback to concerned team members.

Summary
2006 has been a year in which large-scale SOA projects have been appearing with increasing regularity. As such, a need for an all-encompassing methodology for infrastructure development was derived to complement existing service development methods. The first article in this series focused on analysis for en masse SOA enablement with the artifacts of the analysis being a system requirements set that specifies services, and infrastructure requirements that specify non-functional aspects. In this article a design method was prescribed that began by urging that an SOA development center (SDC) be created to act as a repository for design artifacts, as well as a collaboration and oversight point. Hardcore design began with the precipitation of preliminary design choices from the well-established SOA infrastructure reference model. Next, a sub-method for rehashing and repurposing existing enterprise aspects for the SOA was espoused, followed by the important design step of developing ontologies of change. Integration design was discussed, with an emphasis on mediation and data composition, followed by a treatment of user interface design best practices and how they affect SOA infrastructure. The article concluded by specifying the creation of a detailed design that leads to the end-goal of a future-state architecture specification and roadmap. The build/test phase was addressed and tied back into the iterative design process.