A good architecture governance capability has at it's heart a focus on developing people and encouraging excellence (see Governance Without Goodwill is Dead). I like to think of it in terms of a leadership capability of the sort alluded to in this Dwight Eisenhower quote:
"Leadership is the art of getting someone else to do something you want done because he wants to do it."With that backdrop, and as part of an emerging governance program, I've recently had the need to introduce or reinforce a set of service design principles to a large audience and begin developing a shared and actionable understanding of these practices. The goal is to increase community awareness and support for good design and to further develop good design skills throughout the community.
A good source for this material is Thomas Erl's SOA Principles of Service Design
, and many in the community have been encouraged to buy the book. In fact, we've given away a couple dozen of them. To further jump-start the process, it has been helpful to create a high-level representation of these principles that can be used in introductory sessions and training. Doing so has begun to instill a common language and frame of reference.You can download a copy of the design principles document. It's a bit large due to the graphics. Following is a quick preview.
Standardized Contract - Implement a standardized contract
Services within the same service inventory are in compliance with the same contract design standardsLoose Coupling - Minimize dependencies
Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environmentAbstraction - Minimize the availability of meta information
Service contracts only contain essential information and information about services is limited to what is published in service contractsReusability - Implement generic and reusable logic and contract
Services contain and express agnostic logic and can be positioned as reusable enterprise resources
Autonomy - Implement independent functional boundary and runtime environment
Services exercise a high level of control over their underlying runtime execution environmentComposability - Maximize composability
Services are effective composition participants, regardless of the size and complexity of the compositionStatelessness - Implement adaptive and state management-free logic
Services minimize resource consumption by deferring the management of state information when necessaryDiscoverability - Implement communicative meta information
Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted
Hope you find this useful. To learn more about these principles, be sure to get a copy of SOA Principles of Service Design
and download a copy of the design principles document.
![[hot]](http://bsonderg.googlepages.com/star_on.gif){kind=small}
Save This Page
3 comments:
I get the value of road showing SOA principles and practices to a mass developer audience, but is that really the target to hit? Seems to me the value of SOA isn't as much the "now" as the "future." Does communicating the "future" to a tactical audience yield optimal success?
Thanks for the comments, Bill. This is definitely worth some further discussion. Here's the way I look at it.
Let's think about it from two perspectives. First, from the stand point of innovation, it's important to take into account "diffusion of innovation" research that helps us to understand "how, why, and at what rate new ideas and technology spread through cultures" (Wikipedia). Research indicates that adoption of new ideas or opportunities typically follow a common life cycle from awareness through interest, evaluation, trial, and finally into adoption. If we look at processes that encourage successful innovation, it's important to apply energy that deliberately drives through these stages of the life cycle. From that standpoint, we see the importance of maximizing awareness.
Shifting the perspective to that of change management, it's been my consistent experience that meaningful change comes only when there is a healthy blend of "top-down" and "bottom-up" or "grass roots" support. Change management theory teaches us the importance of creating within the change system a level of energy and enthusiasm that can counter the often overwhelming forces that operate against change. The grass roots enthusiasm is one means of creating that sort of energy, especially when the support comes from a broad and diverse population. When combined with the "top-down" support, this type of enthusiasm creates a sort of "fly wheel" effect and generates momentum that can overcome the inertia of immobility.
So, "diffusion of innovation" encourages us to maximize awareness, and "change management" suggests the importance of broad and diverse grass roots enthusiasm. Taken together, it's clear that we need to approach change differently - especially when we're talking about cultural change. It's essential that we engender the broadest possible conversation. Of course, that conversation must take place among various disciplines and at various levels. Encouraging the development community to embrace an increased understanding of good design principles is just one small part of the puzzle.
There's another angle I'd like to touch on briefly. You asked, "does communicating the 'future' to a tactical audience yield optimal success?" If I understand correctly, we're labeling the development community as tactical operators. Given modern business demands to deliver ever increasing levels of business agility, I'd like to hold this group of "thought workers" to a higher standard and expect us all to contribute by maximizing our strategic contribution. After all, what we do now is precisely what creates the future.
Thoughts?
Interesting response and thank you for the thorough time it obviously took. I'll take the bait on the tactical v. strategic development with this angle. In the transmission example, the operator "identified" you as a prospect, "sold" you on the transaction, and "executed successfully."
How often do we live that model ourselves? Todays post by Jeff Atwood demonstrates, cynicallly, the model.
http://www.codinghorror.com/blog/archives/001082.html
My comment on a software developer being a "tactical" party to a transaction was probably (definitely) a poor choice of words. Most software engineers / developers that I have ever met have a strong hunger for business knowledge probably because they, more than most, understand the lack of value in building a feature that doesn't make the market release. I think unfortunately though large organization infrastructure and overhead combine to limit curiousity beyond the specific feature. I don't often see a project where the entire team is lead to a shared vision of something great in its entirety, not just the sum of its features.
I agree with what I presume to be your point that we should try harder.
Post a Comment