SOA Master Class Education Training and Free Downloads

I understand the reaction people have to the phrase SOA Governance.

Mike Meehan of SearchWebServices says:

…let?s be honest, the term ?SOA governance? sucks. It reeks of someone else telling you what to do, hectoring you over every little detail of a project. It sounds about as desirable as a colonoscopy with an IMAX camera.

Still, I’ve wound my way around and around this thing and keep coming back to it.

We have a phrase at Software AG webMethods which is “Liberate and Govern”, which are two sides of the same coin. Perhaps “regulate” might be a better word, but if we’re planning to ditch “govern” we had better move to something a lot better. Regulate doesnt really get me excited either.

The interdependencies in SOA drive complex systems and therefore emergent behavior. Governance as a term fails to capture the essence of the notion of complex behaviors made emergent by the use of simple rules of engagement. I’ve been favoring the word “Coordination” lately, which evokes a flock of geese or ordered “swarm” behaviors.

So I think we are stuck with the term, but it’s important to recognize that we are talking about the emergent behavior of complex systems. If we want to consider the entirety of the system which should include the Service Pattern, the Process Pattern and the Event/Exception/User Pattern (most broad definitions of SOA do), then we need to understand that SOA Governance is a fully human cybernetic system and therefore subject to dynamic systems principles.

The Tao Te Ching chapter 59 is clear on this subject:

In caring for others and serving heaven, There is nothing like using restraint.
Restraint depends on giving up one’s own ideas.
This depends on Virtue gathered in the past.
If there is a good store of Virtue, then nothing is impossible.
If nothing is impossible, then there are no limits.
If a man knows no limits, then he is fit to be a ruler.
The mother principle of ruling holds good for a long time.
This is called having deep roots and a firm foundation, the Tao of long life and eternal vision.

Another translation of the same verse

Chapter 59

In governing people and serving Heaven
There is nothing like conservation
Only with conservation is it called submitting early
Submitting early is called emphasis on accumulating virtues
Accumulating virtues means there is nothing one cannot overcome
When there is nothing that one cannot overcome
One’s limits are unknown
The limitations being unknown, one can possess sovereignty
With this mother principle of power, one can be everlasting
This is called deep roots and firm foundation
The Tao of longevity and lasting vision

The second translation uses the phrase “governing people” whereas the first says “caring for others and serving heaven”. The goal in both is stated to be the establishment of deep roots and a firm foundation for longevity. That’s really at the heart of SOA and SOA Governance.

My 2 cents,
Miko

Be first to comment this article | Add as favorites (0) | Quote this article on your site | Views: 6472

Bookmark Article
Blink	Del.icio.us	Digg	Furl	Google	Simpy	Y!	Spurl

SOA is part of an industrial revolution in software. It’s driving an assembly model for software components which provides “business agility�. What does that mean? It means that about 90% of software in the enterprise can be thought of as reusable commodity components or “legos� and that the other 10% represent the competitive differentiation of that organization vs others.

Whenever someone comes up with something new (innovation), how does that get implemented, and what does governance have to do with it? Well, innovation becomes execution when all the stakeholders responsible for delivery adopt the new idea.

Have you ever tried to get an Enterprise to adopt a new idea? Typically a dozen groups come out of the woodwork and say “here’s why you cant do that�. This isnt because these people are bad people, they just have responsibilities, constraints, expectations, and people who rely on them to behave in measurable and predictable ways.

So policy is just a way of making these responsibilities explicit rather than implicit. For example, getting back to GRC, the Corporate Governance group has the responsibility to ensure that regulations are being met. Other groups have other responsibilities.

Be first to comment this article | Add as favorites (0) | Quote this article on your site | Views: 7418

Bookmark Article
Blink	Del.icio.us	Digg	Furl	Google	Simpy	Y!	Spurl

In manufacturing, there are several categories of production. A manufacture can be a "build-to-order", "engineer-to-order" or "assemble-to-order" shop. Engineer and build-to-order means they make their products from scratch or raw materials. This is the most flexible, but requires a longer lead time to make the final product and therefore is less agile. Assemble-to-order means that themanufacture take parts called assemblies, put them together in different interesting ways to create the mered of potential final products and thereby increasing agility. An example of this would be Dell Computer. When they take your order, they have lists of options for each area or functionality. These areas would include disk drive, motherboard, ram, operating system, monitor, etc. This ability allows Dell's customer to mix and match their system based on their needs.

 

Service Oriented Architecture gives IT shops the same advantage to their customers. By design, SOA helps engender the "assemble-to-order" mentality that is needed in order to become agile. In these terms, an SOA service is functionality. It abstracts or hides the complexity of "how to do something." So, this service is the equivalent to the assembly part in the manufacturing process.

Be first to comment this article | Add as favorites (0) | Quote this article on your site | Views: 9597

Bookmark Article
Blink	Del.icio.us	Digg	Furl	Google	Simpy	Y!	Spurl

Recently Ive been delving into the specs associated with Web services, including BMPN, WSDL, UDDI, ebXML Registry, and WS Policy. The focus of this research was to determine what information needs to be captured in the requirements and design phase to fully specify the Web service throughout the life cycle.

We had a few email exchanges with Miko Matsumura about policy metadata mainly to determine what type of information is necessary to collect policy requirements (which are part of the business requirements). But after a few go a rounds, and after looking at metadata specs for both ebXML policy and WS Policy, as well as this helpful comparison of the functional capabilities of different repositories (link courtesy of Miko) my conclusion was that what was really needed and sorely missing were templates for different types of policies so when analysts and developers are gathering requirements and designing services, they know what questions to ask and what information to document.

While all the relevant specs contain the information required to implement the service, none guide you in how to gather the requirements or create the optimal design. Our primary focus is on a process driven approach to right sizing Web services, but I am becoming more convinced of the need in the market for service patterns that can help developers identify different types of services that need to be implemented. These templates can then be implemented in UDDI (or the repository extensions based on UDDI) through tModels, which are technical models that represents reusable concepts. Examples of useful reusable templates which could be implemented in tModels include an implementation model for transactional services, or a data lookup service.

Identifying service patterns will help guide developers beginning SOA implementations to understand how to think about the types of services they need to implement. The types of patterns were looking at are types of service behavior (agents, monitors, stateful, stateless, long-lived, short-lived, transactional, etc.), service communication patterns (synchronous, asynchronous, request/reply, publish and subscribe, 1 to 1 messaging), and types of service policies (security policies, version control, SLAs, etc.). Once we have the reference models for each of the different types of services the models can be implemented a tModels and just configured for each service instead of created from scratch. This is somewhat of a cook book approach to SOA.

I?m asking here for a reality check here. Do you agree this would add value to SOA efforts? What do you think would be helpful and useful in helping analysts, architects, and developers evolve SOA within the organization?

Be first to comment this article | Add as favorites (0) | Quote this article on your site | Views: 9391

Bookmark Article
Blink	Del.icio.us	Digg	Furl	Google	Simpy	Y!	Spurl