ServiceTechMag.com > Archive > Issue LX, March 2012 > SOA Governance in 3-D
Yves Chaix

Yves Chaix

Biography

Yves is an IT Consultant living in Nicaragua and specializing in eGovernment and service-oriented architecture (SOA) systems and solutions. Yves is currently a SOA Certified Professional (SOACP), Consultant, Analyst and Architect. He also acts as the moderator for the LinkedIn group dedicated to the "Prentice Hall Service-Oriented Computing Series from Thomas Erl".

Yves co-authored the Spanish SOA Manifesto and the Spanish version of the Annotated SOA Manifesto. He co-authored, with a group of French and Belgian SOA experts, the French versions of these documents as well. Yves is also responsible for translating the "SOA Principles of Service Design" book as well as the SOA Glossary into Spanish.

Contributions

rss  subscribe to this author

Bookmarks



SOA Governance in 3-D

Published: March 23, 2012 • Service Technology Magazine Issue LX PDF
 

Abstract: 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.


Introduction

Waiting for the SOA governance book [REF-1] 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.


The Problems with a 2-D Model

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 (running the SOA governance program). But this step is also the one that executes the SDLC stages, isn’t it?

What are the Actual Limits of the Model Context?

What are the contextual input, controls and output? (The roles or mechanisms are generally easier to map). What do we start with? What is assumed as pre-existing?

SGPO jurisdiction models, service funding models, the definition of precepts, the institution SDLC model, etc. seemed like good candidates, as well as using business requirements, goals and stakeholders as input.

This was a real issue, because it all had to do with how and when an SOA initiative actually starts. This raised the questions, what is part of the model and what happens prior to establishing it?

Starting out, these questions were expected to be solved with the IDEF0 model.


Developing the Model

Actual Limits of the Model (Context)

An SOA initiative might start as a consequence of establishing business requirements and goals, or as a result of identifying external shifts, which generate challenges or opportunities.

At some point, when problems arise someone who has heard of SOA will say "I've heard that this thing (SOA) might help us". And if this person starts investigating, he/she will either contact an SOA consultant or start studying to become one.

Assuming that the issue is urgent, an SOA consultant will come in and bring a theoretical or conceptual bibliography and personal experience that will act as external controls to the whole process. This is where we will find things like SOA principles and SOA design patterns. At a later time, we will see the SOA SDLC model, precept definition, SGPO jurisdiction models, and the service funding model. Eventually, SOA best practices and common pitfalls added to the model will arise during the later stages of implementation (Figure 1).



Figure 1 – Context Level.
(Click here for larger image)


Our SOA consultant – under the recommendation of the SOA governance specialist, of course - will probably start by proposing a three steps implementation approach (Figure 2):

  • Step 1:Assess the enterprise or domain
  • Step 2: Plan and build the SOA governance program
  • Step 3: Run the SOA governance program (best practices and common pitfalls) and the SOA SDLC

These three steps are clearly distinct, because they cannot be run concurrently. After the assessment in step 1, senior management will have to make the decision whether to continue, so step 3 cannot be started before step 2 has concluded.



Figure 2 – First Level.
(Click here for larger image)


If our consultant has received enough empowerment (or money), he/she may then move on to executing step 1 – assessing the enterprise or domain. This step will probably use at least the SGPO jurisdiction models and the service funding model as controls, and will receive as input the business requirements and goals, stakeholders and some amount of organizational information gathered on site. The output of step 1 will be the strategic goals and benefits that will serve as controls for step 2 and input for step 3 and, of course, the enterprise/domain assessment which will serve as input for both step 2 and step 3.(The 3-D model is more powerful and allows for a better evaluation of the interrelationship between all these steps than what a book can offer.)

Step 1 represents the very first thing that any SOA initiative must take on, at least for the first time. This step will generate the strategic goals and benefits as well as the enterprise or domain assessment, which will actually launch the project (Figure 3).



Figure 3 – The Main Activities of Step 1.
(Click here for larger image)


One of the major challenges that can occur at the beginning of the endeavor is in establishing the direction of the relationships between the processes and the precepts from the diagrams in the governance book. A few hours (yes, hours) were necessary to eventually discover that no process actually describes the generation of any of the precepts described in the book, but that the precepts are assumed only as CONTROLS to the processes (while the roles are consistent with the IDEF0 semantic). So, the precepts have to be created somewhere during the process.

Another challenge was that of the output of the processes: there were mostly none. Sometimes the description of the process would mention a deliverable, in which case modeling was made easier, but in the rest of the cases, the name of the output had to be derived from the name of the process itself. Obviously, the reader will have immediately realized that some processes might actually generate more than one output. That is a benefit of modeling the workflow.

The inputs were the great mystery: it is difficult to conceive processes without input. (Controls are sometimes treated as input in IDEF0, but in this context, controls are controls, not input).

In some cases, the process, precept or role descriptions are allowed to assume a certain input, but in most cases, the input just had to be inferred from the context logic. This obviously introduced some subjectivity and lots of unsupported flows too. But the processes eventually got all or most of their input.

So, what about the generation of the original controls, the precepts, the guidelines, the policies, the standards, the metrics, the vitality triggers? Somebody has to generate them through some process, right? Well, this is basically the role of Step 2, planning and building the SOA governance program as per the following figure:



Figure 4 – The Main Activities of Step 2.
(Click here for larger image)


How should this step be organized? The governance book made it fairly easy. One process was created that was in charge of generating all the precepts, metrics and the additional components. This roughly followed the order of the chapters for the precepts that are expected in chapters 8 to 12, and all of them were grouped under the general flow “SOA Governance Precepts”, while metrics are grouped according to classification in pages 166 to 168.

As can be seen (Figure 5), the large amount of generated precepts makes for a somewhat un-elegant diagram. Readers familiar with the IDEF0 notation will note that level A3.1 has been omitted. (There are at the moment a total of 157 activities in all levels, showing them all is unnecessary.)



Figure 5 – The Activities Involved in Creating the Precepts.
(Click here for larger image)


The next diagram (Figure 6), models the generation of the different types of metrics, except that, in this case, the metrics were not identified individually to make the diagram more readable.



Figure 6 – The Activities of Generating the Metrics.
(Click here for larger image)


Having finished the review of Step 1 and 2, it is possible now to look at Step 3 and how it was managed. Step 3 is a very important step since it establishes the first actual direct relationship between the SDLC and the governance process. Step 1 and 2 were pure governance processes.

For Step 3, it was necessary to create the SDLC with all its stages from SOA Principles of Service Design [REF-2] and other books from The Prentice Hall Service-Oriented Computing Series from Thomas Erl [REF-3]. But then, what about the governance activities? It was necessary to go back to the book where these activities are presented as processes, however no input/output definitions were found from the SDLC activities to the governance processes. By modeling the SDLC activities, it became possible to generate the SDLC deliverables and make some assumptions about inputting them into the governance processes (Figure 7).

IDEF0 had to be pushed to its limit by creating a page with the maximum number of seven processes as per IDEF0 specifications. It is a little messy and may sometimes have to be reworked, but it will do for the time being.

Now we have another challenge: only four activities (found in chapters 8 to 11) are actually related to the SDLC, the other three are more ancillary: governing service information & policy, SOA vitality and SOA technology. So, the decision was made that each stage of the SDLC would include a governance activity, which would receive its input from the SDLC and generate the expected governance deliverables.



Figure 7 – The Main Activities of Step 3, which Combines Both the SDLC and the Governance Processes.
(Click here for larger image)


The activities in green are the SDLC activities proper. The other three are autonomous ancillary activities, not directly related to the SDLC.

The next figure (Figure 8) models the inventory and service analysis process. The two SDLC processes and the governance process associated to the SDLC processes are shown here as well.



Figure 8 – The Activities of Running & Governing Service Analysis.
(Click here for larger image)


Figure 8 introduces the SDLC deliverables and a preliminary decomposition per activity. The only input from the SDLC deliverables into the SOA analysis governance is the “modeled candidate service and capability,” but if SOA quality management is included – in the future – in this process model, then it is probable that most or all the SDLC deliverables will have to become input of the SOA analysis governance process.

Readers familiar with SOA principles of service design will recognize in Figure 9 the SDLC processes for the service inventory analysis.



Figure 9 – The Activities of the SDLC Service Inventory Analysis Processes.
(Click here for larger image)



Conclusion

With the input from the SDLC activities, governance can get to work (Figure10) on executing the processes described in chapter 8 of the governance book – with their respective input, controls and roles. Each process will generate its own deliverables (the business heat map, the approved, deferred or rejected changes or extensions to service candidates) lumped together under one global flow of “governance deliverables”.



Figure 10 – The SOA Analysis Governance Processes and Deliverables.
(Click here for larger image)


This concludes the excerpts from the 150+ activities for the SDLC and governance processes. However, with the coming new modules on SOA quality management/assurance, it is obvious that a whole set of new activities will have to be included that are not covered by the SDLC or the governance workflows. This will be the object of a new version of this review.


References

[REF-1] Erl, Thomas, et al., SOA Governance: Governing Shared Services On-Premise & in the Cloud, Prentice Hall, 2011. www.soabooks.com/governance

[REF-2] Erl, Thomas, SOA Principles of Service Design, Prentice Hall, 2007. www.soabooks.com/psd

[REF-3] “The Prentice Hall Service-Oriented Computing Series from Thomas Erl”, www.soabooks.com