Governance plays a critical role in the success of our SOA projects. However, the fog and friction of development hinders the effectiveness of enforcing governance policies in our service-oriented analysis and design (SOAD) efforts. Adopting a process and a toolset, consulting documentation and participating in skill building events are the typical first steps taken by organizations as they combat the fog and friction of development. However, learning, internalizing and effectively executing a process and set of tools can be an exercise of frustration. This article discusses how to use automation to apply patterns, validate designs and summarize details to amplify the efforts and skills of teams in SOAD. By using these approaches, we are better able to align business and IT, ensure proper investments, and track and enforce adherence to best practices, all of which combine to bring process and governance to life.
Service-oriented analysis and design (SOAD) encompasses the tasks, deliverables and workflows that lead to the creation of service-oriented (SO) solutions. This includes the efforts across business modeling, service identification, service specification, and service realization.
SOA governance empowers and enables the people within the organization to successfully perform SOAD and deliver SOA solutions. People become empowered by establishing chains of responsibility, authority and communication. We enable people to carry out their roles and responsibilities by establishing measurement, policy and control mechanisms. The team must use the same best practices, improve communication, and support measurement and traceability. The focus of such efforts is to ensure business-IT alignment, reduce risk, ensure proper investments, support reuse, and deliver quality solutions in a timely manner. You might start out successfully with your SOA initiative, but without SOA governance from the beginning, you will start to see a greater usage of resources to maintain your existing services, and start to lose the value of moving to SOA in the first place.
Realizing the potential and promise of SOA is best achieved through the successful application of SOAD along with SOA governance. However, our efforts need to overcome the fog and friction associated with any significant undertaking. That is, are we able to gather reliable information and reduce the fog surrounding our efforts...
SDLC and governance processes are difficult to model in a book because it is a 2-D model. This article describes how both SOA SDLC and SOA governance processes described in "SOA Governance: Governing Shared Services On-Premise & in the Cloud", can be modeled with IDEF0 to allow better visualization for the processes´ inputs and outputs, thereby creating a complete workflow. In this model, the SOA governance precepts are created as controls to the SOA governance and SDLC processes. The SDLC outputs feed the governance processes to establish the SDLC-to-governance chaining. The IDEF0 methodology allows drilling down the activities to create a 3-D model.
Waiting for the SOA governance book created anticipation and its release was no deception. The book is great, except for the fact that it is a book. Books are nice to carry around and show off, but they are two dimensional. Workflow processes are quite difficult to represent in a book: no drill-down on activities, no clicking on arrows or on activities to see their content. Fans of workflows will understand this, particularly IDEF0-forever fans. Although BPMN seems to be the next replacement, BPMN diagrams can´t be shown to non-IT customers, whereas customers understand IDEF0 at first look. IDEF0 is as intuitive as it comes. This article explores how different parts of the book can be converted into an IDEF0 model. A UML activity diagram or any other process diagram tool might have been used, but IDEF0 was definitely the first choice.
It was clear that the book had all the answers, but its format presented some challenges. What was it that could not be dealt with?
No Explicit Input or Output in the Diagrams
Without explicit process input or output, it is practically impossible to build a mental model where all processes are linked.
No Explicit Relationship between the Governance and the SDLC Processes
At what level should the governance processes be separate from those of the SDLC? What are the SDLC deliverables that feed the governance processes? What about quality management? Should it not be part of governance also?
Where are the General Governance Controls Generated?
The general logic seems to be that precepts, guidelines, metrics, and vitality triggers are all generated as controlling documents in Step 2 (planning and building the SOA governance program) and are then used as controls for Step 3...
The second part of this two-part article series uses symbolic notation to apply principles and patterns to a use case. It proposes an approach that starts with meta-questions and ends with more detailed questions that equate to design patterns. Using as an example the design of a claims service, it suggests a methodical approach to identify design patterns that support a service-oriented architecture. To read the first part of this article series, click here.
In the first part of this article series, we tried to come to grips with the human element of creating and delivering a successful SOA by focusing on the necessity of strong leadership. In this part, we'll apply two principles to building a claims service using patterns and the notation that was outlined in the first part of this article series.
Embrace boldness and scorn perfectionism to get take-off velocity. A successful SOA sometimes means jumping into the deep end of the pool to master WSDL development and XML schema in particular. In terms of tools, there are many simple, robust vendor and open source drop-and-drag products.
An approach that spins wheels is to observe a strict waterfall methodology where we freeze progress while we try to answer all questions. However, asking lots of questions often raises yet more questions. This is at the heart of building our SOA.
Someone asked the poet Gertrude Stein on her deathbed, "What's the answer?" She replied: "What's the question?" Often we don't need more answers but just better questions. Are our foundational assumptions sound? Is there different or new information or alternative assumptions that could change our SOA? The best way to evaluate SOA readiness is by getting credible answers to the following questions:
How well prepared is our organization to embrace significant change?
Do we know where our business rules are?
Is our data flexible and do we trust its quality?
In TOGAF, these questions are raised during the preliminary phase where in general terms of who, what, where, why, and how are defined. We have answers to some those questions in the form of patterns. TOGAF architectural development is incremental and iterative. Thus, adjusting patterns as we think through the implications of our architecture is necessary. We should capture our understanding of the patterns in a metadata dictionary. This will let us cross-reference by keyword problems, solutions, impacts, extensions, and applications, leveraging that knowledge for future development...