Understanding Enterprise SOA: Book Review

I was handed this book by one of my programmers. He lent it to me because he knew I was doing some reading on the subject and trying to work out how to bring my software developers up to speed with SOA. I didn't get the impression that he had got terribly much from the book himself. After reading it I can see there is benefit for managers but I think there was not enough technical meat in the book for programmers and analysts.

This book is not technical. It can be read by managers, salesmen or students and I think these were the intended audience. The explanations are easy to understand although I found them long-winded and overly simplistic on many occasions.

The authors attempted to explain procedural code as if it was museum artifact. This made me feel very old. It begs the questions whether the developers brought up on object-oriented development and SOA really need a detailed explanation of the concept of procedural code.

On the positive side this books tackles issues that others do not. It has a good non-technical discussion about security issues and there is a lot of discussion about human issues such as training, reorganization and corporate culture.

Oddly for a book written in 2006 I did not find any mention of Enterprise Service Bus (ESB) although it was clear the author was encouraging looking at off-the-shelf SOA management solutions as well as SOA security and routing software.

Eric Pulier in his preface is unbridled in his enthusiasm for SOA standards:

In a spectacular cycle of enlightened self-interest, every major company in the world has build on top of standards which have ushered a potentially exponential release of value from investments in information technology.

Elsewhere in the book there are sufficient cautions to temper this enthusiasm. In particular the authors advise that much of SOA is still hard work and that there are no industry standard solutions to problems such as transaction processing and security.

There is a long and detailed case study running through the book. The authors do not hold back on the multitude of issues that confront an organization adoption SOA. Parts are realistic and even painful for those of us who have been through implementations of a difficult project or technology.

The book has a good history of technologies and standards. The authors make a good point about standards conforming to the Tipping Point model (see references below). This is when a standard reaches a certain level adoption that it suddenly becomes desirable for the majority of developers.

This is not a strong academic text. There are not many references to other information sources. The definitions are not clearly stated and often over-simplify the concepts. Concepts like Enterprise Architecture, Real-Time Computing and loose coupling are all not accurately defined.

"Loose-Coupling" is described but not adequately explained. The authors give the impression that loose-coupling is only about where you can locate services.

Web services, in contrast are loosely coupled. Once a piece of software has been exposed as a web service it is simple to move it to another computer.

This is an important aspect of coupling but is not the whole story as I have identified on previous postings.

The book focuses on synchronous services rather than asynchronous services. This is unfortunate as other texts such as Thomas Erl or Krafzig, Banke & Slama seem to advocate asynchronous services.

The book addresses the Subject of Enterprise Architecture again loosely defined. At one point the book states

There is no institute providing credentials for enterprise architects.

I'll give the authors the benefit of doubt. Perhaps in 2006 there were not the credentials around but these days there are a number of places to get recognized credentials as an IT Architect. The Microsoft Certified Architect programs spring to mind although I will not vouch for the content of these programs.

The authors see SOA as a method for replacing parts of the Data Warehouse. I was not particularly convinced by this. This was an interesting subject which I had not seen before. I think there is benefit in moving the content of SOA logging to the data warehouse but I was not convinced that SOA radically changes the typical data warehouse ETL process.

This is not a book with detail examples of SOAP and WSDL. It will not explain how to code or build services. You will not find much detail on WS-* here either.

Contracts and Service Level Agreements (SLAs) are described in the book. The authors also introduce the Business Level Agreement (BLA). This is agreement to monitor business conditions such as an inventory pile-up causing $100k per minute of cost.

The book is well illustrated with copious diagrams and notes attached to the diagrams. I found myself skipping past a lot of the diagrams because they did not seem to be explaining anything particularly special.

I congratulate the authors for including detail about setting up training programs in the book and explaining how the resources are brought in to deal with the adoption of SOA. This is missing from many other texts and is an important issue today.

The authors emphasize that SOA is an enterprise approach. Under SOA, IT departments put in place infrastructure to serve the enterprise rather than just serving particular applications.

I would recommend other books before this one for most audiences. The simplistic and at times pedantic prose would make it hard to recommend to an IT professional. Nevertheless there are some well-made observations in this book that you are not likely to find elsewhere.

References

Understanding Enterprise SOA, Eric Pulier and Hugh Taylor with forward by Paul Gaffney, Manning, 2006

The Tipping Point: How Little Things Can Make a Big Difference (ISBN 0-316-31696-2) is a book by Malcolm Gladwell, first published by Little Brown in 2000.

Will BPM be the Savior of SOA?

My friendly Software AG representative recently gave me a copy of the "BPM Basics for Dummies". This was an interesting little book pitched at the Executive level. It would not help an IT person to get started with any particular product set but would help them understand what all the fuss was about.

BPM (see note below) has been with us since at least the 1980s. It used to a paper process of writing up the process and then getting a team of programmers to build it, then implementing it on usually a big computer that could handle it and then have the computer operators monitoring it.

In the 1990s Business Process Reengineering (BPR) was an approach which changed an organizational process. It involved process diagrams, IT change and business change.

The excitement with BPM is that some of the leg work involved in actually building systems can be removed if the components of the business process are already established. In this case the components are Web Services enabled through an SOA.

What interests me about this is that some of the concepts behind BPM are a lot easier to explain to the business than SOA. You can get out the Lego blocks and explain the benefits of agility until you are blue in the face but you are still only talking in analogies and expecting the business to take a leap of faith. If you show the business a diagram of one of their business processes and then tell the business the cost of changing that business process then that makes sense in terms the business understands. Of course there is a significant investment in infrastructure, tools and services to establish before you get to that point. It is this significant investment that the IT executive wants to sell. If you are pushing a plan to buy infrastructure, tools and establish services then the plan will make more business sense if the objective is BPM rather than SOA.

I think Software AG understands this and that is why they are giving out "BPM Basics for Dummies" and not "SOA Basics for Dummies". I think the business will get behind BPM before they will embrace SOA. We may see more push for BPM to business executives and SOA may take a back seat. The IT department however knows it needs SOA to get BPM to work. That is just how it meets the business goal of BPM.

Note:

BPM stands for Business Process Management, but you would excused for thinking it stood for Business Process Modeling. The "Management" implies that we are doing a lot more than mapping out the processes. The "Management" moves beyond documenting the processes to making them happen and monitoring their effectiveness.

This is not to be confused with BPMN (Business Process Modeling Notation) where the "M" stands for "Modeling". BPMN however can move beyond an aesthetic model to an operational system by converting it to BPEL.

References:

http://www.ebizq.net/hot_topics/bpm/

http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf

http://en.wikipedia.org/wiki/Business_process_reengineering

Kiran Garimella, Michael Lees and Bruce Williams, "BPM Basics for Dummies (Software AG Special Edition)", Wiley Publishing Inc. 2008.

Laws of Software Development

I ran across an new eponymous law while reading "Understanding Enterprise SOA" by Eric Pulier and Hugh Taylor.
Pulier's rule of reuse:

A programmer will look at another programmer's output, no matter how brilliant and declare it garbage

The best law's and rules are named by others who admire the author's work, but this one seemed pretty worthy to me. This got me reminiscing about some laws of software development that perhaps had the same rigour as Newton's Laws, Boyle's Law or Hooke's Law.

The rules I have admired during my career are:

Brooks's Law:

adding manpower to a late software project makes it later

Hofstadter's Law:

It always takes longer than you expect, even when you take Hofstadter's Law into account.

Codd's Rules of relational database management systems which I won't quote here because there are 13 of them.

Moore's Law:

The number of transistors that can be inexpensively placed on an integrated circuit is increasing exponentially, doubling approximately every two years.

This has a number of applications outside of transistors such as processing speed, memory and disk capacity.

Clarke's 3rd Law:

Any sufficiently advanced technology is indistinguishable from magic.

The reason I class this as a software development Law is that it points out the futility of trying to explain the technical details of software to Business users. If a technical decision does not have any business impact then it may as well be magic.

I thought I would check what other software development Laws there are on the net. Here is a good sample from some useful sources listed in the Bibliography below:

Amdahl’s Law

The speedup gained from running a program on a parallel computer is greatly limited by the fraction of that program that can’t be parallelized.

Asimov's laws (Yes its SF but one day a software developer might have to follow them):

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey orders given to it by human beings, except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Atwood’s Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript

Bye's First Law of Model Railroading

Anytime you wish to demonstrate something, the number of faults is proportional to the number of viewers.

Clarke's 1st Law:

When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.

Clarke's 2nd Law:

The only way of discovering the limits of the possible is to venture a little way past them into the impossible.

Clarke's 4th Law (He's not often credited with this one):

For every expert there is an equal and opposite expert.

Conway's Law:

Any piece of software reflects the organizational structure that produced it.

Edwards' law

You cannot apply a technological solution to a sociological problem.

Greenspun's Tenth Rule of Programming (There actually are no rules 1 to 9)

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp

This can also be worded “Those who do not understand Lisp are doomed to reinvent it.”

Gustafson's Law (also known as Gustafson-Barsis' law)

Any sufficiently large problem can be efficiently parallelized

Kerckhoffs' law on secure cryptography

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge

Lehmann's Laws

1. Systems that are used must change or automatically become less useful
2. Through changes the structure of a system becomes ever more complex and more resources are needed to simplify it

Linus's law — named for Linus Torvalds,

given enough eyeballs, all bugs are shallow

Lubarsky's law of Cybernetic Entomology:

There is always one more bug.

McLuhan's Law:

If it works it's obsolete.

Metcalfe's law

In communications and network theory, states that the value of a system grows as approximately the square of the number of users of the system.

Murphy's Law

If anything can go wrong, it will.

Occam's Razor:
There are many wordings for Occam's razor and debate about how it is interpreted but from software development I think the best wording is "The simplest solution is usually the best". This is very nearly the same as the KISS principal "Keep it simple stupid".

Putt’s Law:

Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand.

Sturgeon's Revelation (sometimes referred to as his second law):

Ninety percent of everything is crap

Weinberg’s Law:

If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

Wirth's law

Software gets slower faster than hardware gets faster.

Zawinski's law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Here are still more great laws from Joey DeVilla's Blog posting.

The Law	Who Said It	What it Says
Ellison’s Law of Cryptography and Usability	Carl Ellison	The user base for strong cryptography declines by half with every additional keystroke or mouse click required to make it work.
Ellison’s Law of Data	Larry Ellison	Once the business data have been centralized and integrated, the value of the database is greater than the sum of the preexisting parts.
Flon’s Axiom	Lawrence Flon	There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs.
Gilder’s Law	George Gilder	Bandwidth grows at least three times faster than computer power.
Grosch’s Law	Herb Grosch	The cost of computing systems increases as the square root of the computational power of the systems.
Hartree’s Law	Douglas Hartree	Whatever the state of a project, the time a project-leader will estimate for completion is constant.
Heisenbug Uncertainty Principle (restated)	Jim Gray	Most production software bugs are soft: they go away when you look at them.
Hoare’s Law of Large Programs	C. A. R. Hoare	Inside every large problem is a small problem struggling to get out.
Jakob’s Law of the Internet User Experience	Jakob Nielsen	Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
Joy’s Law	Bill Joy	smart(employees) = log(employees), or “No matter who you are, most of the smartest people work for someone else.”
Lister’s Law	Timothy Lister	People under time pressure don’t think faster.
Nathan’s First Law	Nathan Myhrvold	Software is a gas; it expands to fill its container.
Ninety-ninety Law	Tom Cargill	The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
Pesticide Paradox	Bruce Beizer	Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual.
Reed’s Law	David P. Reed	The utility of large networks, particularly social networks, scales exponentially with the size of the network.
Sixty-sixty Rule	Robert Glass	Sixty percent of software’s dollar is spent on maintenance, and sixty percent of that maintenance is enhancement.
Spector’s Law	Lincoln Spector	The time it takes your favorite application to complete a given task doubles with each new revision.
Spafford’s Adoption Rule	George Spafford	For just about any technology, be it an operating system, application or network, when a sufficient level of adoption is reached, that technology then becomes a threat vector.

Some unattributed "laws" that are worth mentioning:

• Build a system that even a fool can use, and only a fool would want to use it.
• Any program over 100 instructions can be simplified by 3 instructions (without losing any functionality).
• Any idiot can learn to use computers, and many do
• There’s never time to do it right in the first place, but there’s always time to do it over when it doesn’t work.

This posting started with Pulier's Law: "A programmer will look at another programmer's output, no matter how brilliant and declare it garbage". At the risk of repeating Pulier's conceit of naming law about himself I propose:
Kimber's Corollary:

No amount of documentation is ever sufficient to completely understand a system

Bibliography
http://en.wikipedia.org/wiki/Adages_named_after_people

"Moore's Law is Dead", http://www.techworld.com/opsys/news/index.cfm?newsid=3477

http://en.wikipedia.org/wiki/Change_management_(engineering), This includes the reference to Lehmann's Laws siting Hinley, D.S. (1996). Software evolution management: a process-oriented perspective. Information and Software Technology, 38, 723-730

http://en.wikipedia.org/wiki/Moore

http://en.wikipedia.org/wiki/Occam

http://www.webopedia.com/TERM/C/Codds_Rules.html

Joey de Villa, http://globalnerdy.com/2007/07/18/laws-of-software-development/

Phil Haack, 19 Eponymous Laws Of Software Development, http://haacked.com/archive/2007/07/17/the-eponymous-laws-of-software-development.aspx

Eric Pulier and Hugh Taylor, "Understanding Enterprise SOA", Manning Publications, 2006

Book Review: J2EE and Weblogic

I was drawn to reading the book "J2EE Web Services on BEA Weblogic" by Anjali Anagol-Subbarao because my organization has purchased the Weblogic platform and I wanted more detail about how to make the best use of the tools available in this suite. General books on SOA can tell you about the principals and standards but without actually talking about specific tools there is a big gap between theory and practice.

"J2EE Web Services on BEA Weblogic" was published as part of the Hewlett-Packard Professional Book Series. While the Weblogic content the descriptions of some of the management functions of HP Openview were a bit alienating as I have not used this product. However it did also talk about some useful utilities and open source products that were not provided by either BEA or HP.

While the description of the tools were fairly high level and probably could be translated into similar functions in other suites I do not expect this book attract users of other SOA platforms suites.

The book style is fairly easy to read with some good diagrams and examples. The SOA standards and principles are covered well with a focus on the WS-*, SOAP and WSDL standards.

The basics of J2EE and EJBs are explained and some fundamentals of the Weblogic platform. This is not an evangelistic book about SOA or Web Services but goes into a bit about the technology of how to bring it about. The SOA benefits are there but the SOA story gets a bit lost amongst the instruction on how to use the BEA tools.

Some of the material reads like BEA marketing literature. I would have liked more practical tips on what to use and what not to use. In a book like this we need information that we can't glean from the manuals. This provided the high level overview with out some of the more practical "dos and don'ts".

There is good information on versioning and a good section on evaluating WS management tools. Also the book provides some practical approaches to performance issues.

This book has limited readership and will date quickly. Your best technical advice will always come from the product manuals but this book explains a bit about the suite is used as a whole. Published in 2004 this book is nearing its "use by" date but there is still some relevance to what it describes. Be quick though, with the acquisition of BEA by Oracle we can expect some changes to the BEA product suite.

Lego, Carrots and Coleslaw

I discovered Jeff Schneider's blog archive about SOA and Lego blocks. He has added some great photos. Unlike some other photos illustrating SOA on the web these blocks on the photo are real lego. Jeff discusses accessibility, recombination, composite applications and peer-oriented systems using the metaphor of lego blocks. He also makes judicial used of carrots, cabbage and coleslaw.

I have discussed some of the advantages and disadvantages of the lego metaphor in my earlier posting Lego and SOA. It has also made an appearance in some videos I have seen and conferences I have attended.

Web Services versus the REST

Despite there being much discussion about the relative strengths on between SOAP Web Services and REST it is not actually that often that you make an explicit decision between the two. Once the die is set you will tend use one or the other. Alternatively it may be self-evident which approach gets used for what services.

The decision to use one technique or another is not made very often. Often such a decision is made in series of smaller decisions over a period time. For instance REST may be chosen to be used for some aspect of some project several times over before it assumes the role of accepted practice in an organisation. Often these decisions are not made in a formal way.

This week my organisation had one of those smaller decision points. The solution architect proposed that we use REST or SOAP Web Services for our services. To define the solution architecture fully we needed to decide which one we going to use.

The case for REST was:

• There would be less processing overhead
• It would a less heavyweight solution as far as programming effort
• Easy for service consumers to understand

The case for SOAP Web Services was:

• The project was already using SOAP elsewhere
• Web Services was a standard and REST was a "architectural style"
• Our partners were more likely to adopt Web Services than REST
• The explicit definition of service contracts in WSDL would be an advantage
• Can deal in standard fashion with reliability and transaction issues
• Better for modelling processes (verbs rather than just nouns)

Other points that were considered

• Our organisation is not particularly experience with either SOAP or REST
• We had used other "service" approaches (neither SOAP or REST in the past)

The decision is not a simply a decision between one or the other. An organisation can adopt neither, both for different circumstances or both in combination. Zapthink advises

… the debate about Web Services and REST is as pointless as arguing whether a
hammer or a screwdriver is a better tool.

W3C discuss a scheme for reconciling the two so that SOAP-based services can be used in RESTful ways.

The winner in this case discussed above was Web Services. This does not commit the organisation to using these technique in the future however this decision will influence future decisions to adopt Web Services in favour of REST. The "horses for courses" approach of choosing the best approach for the application will become less likely as the organisation developers expertise and confidence with Web Services.

Notes:
There is some argument about whether REST is Web Services or not. The use of Web Services Description Language (WSDL) in conjunction with SOAP and not REST suggests that SOAP and Web Services are inseparable. I will use Web Services (capital "W" and capital "S") to describe SOAP based services. Many commentators advocate using "web services" as a description of services developed in REST.

Some REST (Representational State Transfer) include

Daniel Rubio
http://www.webforefront.com/archives/2005/05/rest_-_represen.html

Joe Gregorio, December 01, 2004
http://www.xml.com/pub/a/2004/12/01/restful-web.html

Mark Baker et al
http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage

Evolution: The Fittest and the Sexiest

The topic of this blog is "SOA Evolution" so it seems overdue for me to look at the Evolution process. I coined this title to chronicle my organisation's slow but deliberate adoption of SOA. 'Evolution' seemed to be an appropriate term because it was both a slow process but one that would improve our applications. In this posting I will look at evolution more literally and find more appropriateness in the term than I first imagined.

I am reading a book by Richard Dawkins (see references below) on a range of topics but primary about evolution in biology. There are two principal evolutionary processes. One is the survival of the fittest and the other is sexual selection which is the process of influencing the evolution process by the choice of a mate. The success of evolution is its ability to adapt to its environment and to succeed against other species in that environment.

Natural adaptations are gradual and based on the parent life form. The history of the life forms can be discerned in the DNA of the life form. We can determine that humans evolved from an ancestor we share with Chimpanzees from looking at this DNA.

The process of survival of the fittest can be applied to software development technologies. We see various versions of programming languages replaced by later more effective versions. We see whole languages disappear into obscurity (eg. Algol, APL, SmallTalk, ADA) or replaced by new languages. Relational databases took over from set-based or network databases. Software development approaches have evolved from structured programming, to object-oriented programming to SOA. It has been mentioned that SOA was forged from marriage of distributed computing and document-based integration.

Extinction of old approaches is often not as complete as we would like. The Cobol programs and the old database technologies are still around. The old dinosaurs are hard to kill off completely.

As with any evolutionary process the origins of software development are evident when we dig deep. Visual Basic .NET is still saddled with some of the terminology and constructs that were around in DOS Basic. The kernel of some operating systems still contains some anachronisms which would not be used if it were not for historical reasons. Many software systems have parts that were written long ago or copied from other systems that no-one can maintain or just do not make sense in the context of software written today. Some software maintenance tasks are like archaeological expeditions. Unfortunately it is not passive fossils that the software archaeologist finds amongst the code. Some of these historical curiosities actually support critical business functions.

There are some principles from long ago that we do not want to discard though. Just like some of the primitive instincts and emotions buried in the core of our brain there are principles from long ago that should remain in our software. Procedures and functions still have a role in our software as do objects. The development of services does not replace the need for these other means of encapsulation. The principles for strong typing and structured programming still have as much value today as they did thirty years ago.

The mechanism for natural selection process in software technologies is not that different from the animal kingdom. Programmers will rewrite software using new techniques if requirements change. New tools outsell older tools that do not provide the same benefits. New techniques that reduce development time or improve quality replace old techniques.

Just as species become extinct old software technique die from disuse or replacement. Old code does not die off as quickly as some of us would like. It can last forever in our systems if the requirements it fulfils and infrastructure it uses do not shift too markedly.

Charles Darwin had two theories that he espoused in his books "The Origin of the Species" and "The Descent of Man". One could be paraphrased as 'survival of the fittest' and the other once was 'sexual selection'. Sexual selection is where a mate is selected because he or she is bigger, is stronger, is darker, has more colourful tail feathers or has less hair and therefore individuals with these characteristics tend to propagate.

I have briefly explained how the fittest software and development techniques succeed at the cost of inferior versions but it is also true that the sexiest software can be propagated despite any objective superiority. This can happen through good marketing or the support of a major company. Software standards are often agreed upon, even though they may not be the best based on an objective measure of quality. Often the benefit to adopt a standard exceeds the cost of the standard being suboptimal.

'Survival of the fittest' and 'sexual selection' are alive and well in the software industry. I expect SOA to remain an important part for the genetic makeup of future software development even after the term has lost its currency.

References

Dawkins, Richard, A Devil's Chaplain: Selected Essays, Phoenix 2003

Darwin, Charles, The Descent of Man, 1871, http://www.infidels.org/library/historical/charles_darwin/descent_of_man/

Darwin, Charles, The Origin of the Species, 1859, http://www.infidels.org/library/historical/charles_darwin/origin_of_species/

SOA in a Virtual World

Wikipedia defines a virtual world as a computer-based simulated environment intended for its users to inhabit it. Often a computer application is a business process made virtual by the use of computer technology. We therefore have to be careful when discussing the virtualization of computer environments as this may imply a virtual virtual reality.

The only example of virtual virtual reality I have seen is in a Futurama episode. It displayed an arcade booth with the label 'Virtual Reality' complete with a player using stereoscopic goggles and wired gloves. It then displayed another arcade booth with man sitting in a simple chair imaging he was wearing stereoscopic goggles and wired gloves. The caption to this booth was "Virtual Virtual Reality".

If we talk about "Virtual SOA" we must be talking about something that is not an SOA at all. Judith Hurwitz comes close to this when she discusses a "Virtualized SOA" in her article "Is virtualization the foundation of SOA?"

Andrew Doble writes about building a virtual SOA without investing in in-house software like an ESB. I would argue that this is in fact legitimate SOA. The only thing "virtual" about Andrew's suggestion is the ownership of the software tools.

Virtualization and SOA however do go together. Judith Hurwitz defines Virtualization as

"a technique for abstracting the physical characteristics of computing resources
in order to more easily leverage hardware systems, applications, operating
systems, networks, graphics, data or storage so they can be repurposed based on
customer need."

I believe that loose-coupling is the foundation of SOA but virtualization in many cases allows the benefits from this loose-coupling to be realised. The basic examples of virtualization are virtual servers, storage area networks and thin client platforms such as Citrix. These provide infrastructure flexibility for the deployment of SOA software. The design of the software for an application written using SOA is not affected. The SOA discipline should make sure that flexible deployment options can be used.

Manufacturers such as IBM are building business around SOA infrastructure. One thing to remember is that you do not need virtualization to build SOA. An SOA application can be built on a single server if you required, although it should also give you the flexibility to distribute this application and take advantage of virtualization options.

I agree with Lorraine Lawson in her posting "SOA and Virtualization: Complex, Fuzzy Ideas That Go Great Together? ". These two concepts mix well. However SOA is from the software development world and virtualisation is from the infrastructure world. We should beware of talking in terms of virtualizing our SOA. Our CIOs may consider we are sitting in a corner thinking we have an SOA when this is just a virtual reality.

Fry from "Futurama" with a virtual Lucy Liu.

© 2001 Twentieth Century Fox. All Rights Reserved

The Importance of Meta-Projects

The feature video on International Association of Software Architects (IASA) site last week provided. I wish I could reference the speaker and the name of the video but alas last weeks feature video has been replaced by this weeks feature video.

The talk was reasonably pragmatic discussion of Architecture by a staff member of delta airlines. What inspired me to write this posting was that a slide that depicted "Business Enablements" things, like agility and collaboration. It also depicted lists for Business strategy and IT strategy. This is nothing new but it reminded me I need to lift my eyes from the day to day IT projects and see what my organisation is doing for software development as a whole.

This is timely because its time for my branch to put together a plan for next year. Typically this has been very project-focussed. Of course I also hope to put together a good graphic although I doubt whether I can do as well as the delta-airlines chart.

Each business and each IT department has its projects to achieve some outcome for the business. My focus is on application development projects. Often these projects are part of a bigger business project and commonly involve business process changes and infrastructure changes. Another category of projects do not achieve direct outcomes for the business but allow the business or the IT department to undertake these projects in a more effective manner. For business projects these 'meta-projects' is what was referred to as "business enablements" by the IASA speaker. I will not be using the term further as my spell checker says "enablements" is not a real word, and I tend to agree.

To put these in context see the following table

	Business	IT
Goals/Objectives	Business Goals. Mission, Vision and Strategy	IT Strategy
Meta-Projects	Business meta-projects	IT meta-projects
Projects	Business projects	IT projects

There are strong relationships between each cell in the table and its neighbouring cells. The business goals drive the IT strategy and also the business meta-projects. Business meta-projects may drive business projects but also meta-projects may be driven by projects. Neither the meta-project or project is necessarily the driver. This is the same with IT meta-projects and IT projects. IT strategy should drive the IT meta-projects and IT projects.

The IT Meta-Projects that my IT department is engaged in are:

• SOA
• Enterprise Architecture
• Mobility (Supporting mobile computing devices)
• Business Intelligence (Data Warehouse and Reporting)
• Legacy Transition
• Spatial Systems (Geographic Information Systems)
• Online Project (Customer-facing IT systems)
• Identity Management (Authentication/Privileges/Access Control)
• Service Management (ITIL, Request Management, Change Management)
• Performance Management (Individual Performance)
• Cost Efficiency/Consolidation (ongoing)
• Business Alignment (ongoing)

Some of these meta-projects have explicit planning documents explaining the plan. Others are more just acknowledged as the agreed direction of the IT department. Cost efficiency and business alignment are not specific projects but an ongoing focus of attention as they would be in most IT departments.

Some of these IT meta-projects such as Online Project, Service Management, Performance Management and Costs Efficiency have analogous business meta-projects. Business Alignment parallels the business meta-project of customer alignment.

This list of IT meta-projects has not previously been written out. It is surprisingly long, especially given the much longer list of specific software development projects that are on our books. Ideally each of these meta-projects should be explicitly planned, prioritised and monitored.

Meta-projects provide a foundation to the work an IT department does. They could also be referred to as 'foundation projects' but they are not necessarily just internal projects as they may be programs of projects that directly affect the business user. The meta-projects help build the look and the feel of the IT department. They establish its competitive advantage and its identity. Accordingly, it is important to get these meta-projects right and to provide them with the attention they deserve over the more day to day concerns of getting software out the door.

Architecture on Valentine's Day

I attended the Australian Computer Society (South Australian Branch) Architecture SIG this week. It happened that this was on Valentines Day. This drew a few comments about our dedication to the craft of IT Architecture, as we chose to spend the evening talking about architecture rather than with our chosen partners.

There were two presentations. Paul Turner introduced the International Association of Software Architects (IASA) to us. They have just set up chapter in Adelaide and will associate with our Architecture SIG.

IASA is an international professional society for Architects. It provides standards, training, certification and advocacy for Software Architects. Paul discussed some fundamental questions such as:

• What is an architect?
• What is software architecture?
• How can yo prove you are a software architect?

Paul explained how IASA could help answer some of these questions. The main item of interest for me is that one can now be certified as an Architect. You pay for training over a number of months and then get grilled by a board which determines whether you have made the grade. This is an interesting development and will provide some legitimacy to the role and credentials of a software architect.

Adam Davies then gave a demonstration of Ruby on Rails. I had previously heard much about this technology but had not seen it in action. It was a very competent demonstration and it was amazing how much Adam was able to put together in the course the demonstration without resorting to the "here is some code I prepared earlier" fallback. Rails is able to set up sensible defaults to field names, column names and object names and create mappings between these without much overhead. It seemed to be ideal for standalone applications but certainly had some features that would make it valuable in any software development environment.

Coupling Calculus

I have had thread going through this blog on Coupling. Coupling is important because good definitions of SOA are dependent on the concept of 'loose coupling' or more precisely, 'message coupling'. The thread so far has included the following postings:

Cohesion, Coupling and SOA
Bragging Rights on Coupling
AOP: The Worst Form of Coupling
Binding and Coupling
Subroutine Call Coupling
Seven Levels of Coupling or Seven Deadly Sins?
Coupling with Contracts

In the first posting of this series I went back to the origins of the coupling term that was coined by Edward Yourdan to explain good programming practice in terms of subroutines. I then tried to come up with a list of coupling types which would help explain what were good and bad form of coupling.

This served to clarify the concept in my mind but the list of coupling types is not exhaustive and term 'coupling' is still not clearly defined. Coupling is a measure, usually described as 'loose' and 'tight' which correspond to the value judgement of 'bad' and 'good' respectively.

A good measure has numbers that describe it, but this is not yet the case with coupling. I and other authors have attempted to rank coupling types in order of merit with the ranking an implicit measure of coupling.

There have been attempts to measure coupling by looking at program artefacts like variable names and measuring how many times they are referenced. These attempts seem to miss the point by measuring what can be measured rather measuring coupling properly. Some of these approaches are described in footnote 1.

In this posting I try to suggest some definitions relating to coupling. This will not come up with useful numbers but it will try to explore the concept of coupling and may be a basis on which more theory can be developed.

Coupling is about how easy it is to change applications. If one part of an application (module) has to be changed because another part of a program changes then these program parts a tightly coupled. If one module does not have to be changed for changes made to another module then these application modules are loosely coupled. There are a number of programming practices that can be put in place to loosen the coupling between modules. This is good because it reduces the effort required to maintain your code.

The above would seem to be a fairly elementary description. Definitions however can still be made more precise, so that the concept can be analysed in more detail.

Lets say we have two modules A and B in a system S. The number of changes that can be made to A can be defined as C(A).

We can make changes to A because we want system S to do something different, or we can make changes to A for other reasons. We might want S to be produce results more quickly or we just might want A or S to be reorganised to be more easily comprehended. A change to A might not mean any change the output of S.

In order for A to be changed and the result of S to be changed to a desirable result (which may be an unchanged outcome for S) then in some cases some module B would have to change as well.

The coupling between A and B is defined as the effort required to make changes to B as a result of these changes A. For change j then there is work (and cost) associated with this change for systems S say Wj(S). The work in module Wj(A) and module be Wj(B).

Coupling then can be defined in terms of an individual change
Coupling(j) =the work required in B to make change j as a result of the change in Aj.
Coupling(A,B) is the sum of all work require in B for such changes j.

This leaves the concept of 'Coupling Type' to be explained. A system can be organised to reduce coupling between A and B. A coupling type is a way of organising the system. Some ways of organising will mean that a change to A require changes to B. Some ways of organising will mean that B can remain independent of changes in A. Some ways may increase or decrease the work involved in making changes to B when A is changed.

In general a way of organising a system S is O(S) which is another system which produces the same results. This is a change to the structure of the system rather than a change to the outcomes of the system. If we wanted to measure the coupling of a way of organising O then 'all' we have to do is sum all the Coupling(A,B) over all such S, A and B. A coupling type describes a number of ways of organising a system. The coupling associated with a coupling type is therefore the sum of all the Coupling (A,B) over all these ways of organising S.

To express this succinctly:

Coupling between two modules (A and B) of a system (S) is the work required to make changes to a module (B) as result of changes to another module (A) and still produce the desired outcome of a system (S).

A coupling type is scheme for organising the system (S). A measure of the coupling of a coupling type is the sum over all A and B for systems S which conform to this coupling type.

These technical definitions of coupling describe big, practically incomputable numbers. The conclusions we can draw though are

• There is nothing really special about a coupling type. There could be a very large number of these and they are not confined to simple statements about how to pass parameters between modules. My earlier posting attempting to count these is inherently futile expect to provide common examples.
• Coupling is about work relating to a change. I have not defined what I mean by 'work' intentionally. We could count lines of code changed or look at whether logic or data is changing. We count the costs of making these changes (eg. Hours of labour). It is meant to be used in its common sense. If it is necessary to trawl through technical documentation to make a change to one line of code this is still consider then the trawling effort should be consider as part of the work expended for this change.
• Coupling is about systems in general. It is not just code instructions that are relevant. You might have to change constants, configurations, contracts or XML. These need to be considered in the concept of coupling.
• The concept of coupling is relevant to systems theory examples outside of the field of computer science. Systems can also refer to biological or sociological systems (See footnote 2).
• A change may not actually change the behaviour of the system at all but it is still relevant for coupling.
• Coupling at its most elementary level looks at two particular modules, a particular system and a particular change. Thus it sensible to say A is tightly coupled to B in a system S in relation to change j.
• Coupling can aggregated up to the module or level or to the Coupling Type level. Thus we can have A loosely coupled to B. We can talk about a Way of Organisation or a Coupling Type as facilitating loose coupling.
• Restriction have not been placed on A and B. Therefore if B=S we can have A tightly coupled with the rest of the system S. A and B could intersect or A could be a sub-module of B.

It is still important to describe different coupling types and to determine what types promote loose coupling and what types do not. Good practice will reduce coupling for common programming changes.

To determine whether one coupling type is better than another the above suggests we need to enumerate all possible changes and work out which type leaves you with less work involved in one module as result of changes in another. This is obviously impractical but the analyst can do a couple of things to determine a good coupling type. A range of typical changes can be investigation or the coupling type can be looked at in relation to a specific type of change. For instance the benefits of message queuing can be looked at in relation to changing the location or speed of hardware.

This posting has added some precision to the concept of coupling. Counting all the possible ways to change a system is futile, however good and bad coupling will be become evident by looking at coding examples and foreseeing the changes that will be required to any system.


Footnote 1:

The following web pages describe metrics for coupling. These can be based on a static analysis of code or a dynamic tracing of the execution paths. In both cases the emphasis is counting the reference to a variable or type. This has some value in the task of maintaining code but is not a measure of the work required to change one module based on the need to change another. In some cases there may be some correspondence between the amount of work in changing the use of the variable with the number of times it is reference but not generally.

Lethbridge, Timothy C. and Anquetil, Nicolas, Experiments with Coupling and Cohesion Metrics in a Large System, April 2000, https://www.site.uottawa.ca/~tcl/papers/metrics/ExpWithCouplingCohesion.html

Poshyvanyk, Denys and Marcus, Andrian, The Conceptual Coupling Metrics for Object-Oriented Systems, http://www.cs.wayne.edu/~vip/publications/poshyvanyk-ConceptualCoupling.pdf

Glover, Andrew, In pursuit of code quality: Code quality for software architects: Use coupling metrics to support your system architecture, April 2006, http://www.ibm.com/developerworks/java/library/j-cq04256/
FrontEndArt describes one of its products for montoring source code quality include various metrics for coupling, http://www.frontendart.com/monitor/help/node22.html
Diederik Krols provides a blog-site archive which includes the postion "OO-Metrics for Coupling". This provides a coupling metric based on types shared across a module boundary. http://dotbay.blogspot.com/2006_01_01_archive.html

Footnote 2:

The concept of "structural coupling" in systems theory is used to describe co-evolution in biological and social systems. This is where, if entity A evolves then entity B might need to evolve to compensate. There would seem to be more complicated processes at play here than in a computer application.

Kay, Robert and Goldspink, Chris, Towards a Complex Non-linear Systems Theory of Organisation, http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-72/044%20Kay%20Complex.pdf

More on ESBs

One of my for more popular postings has been "ESB or not ESB". I suspect the only reason was the word "ESB" appeared twice in the title and the Google search engine gave it a high priority when people searched on this acronym.

This was cited in an Italian language blog posting by Andrea Gumina which also cited a good posting by Steve Vinoski . Steve's posting is perceptive and has many good comments on it.

Steve is commenting on an earlier posting by Patrick Logan. Patrick describes the concept of an ESB as a "mangy mutt" because it is a " grab-bag of mechanisms that form no coherent whole". I agree with this assessment but feel that the ESB concept will mature. The ESB may be a mechanism to provide some plumbing. Many organisations SOA efforts need that plumbing because the system delivery has a number of leaks.

My organization was galvanized into inaction and has not yet bought an ESB. However we are fairly typical I would guess because we want the vendors products to do 'everything' for us. IT is not our core business and we do not want to worry about location or services, security, integration, messaging etc. We want our developers to focus on business logic and data models specific to the business. If the vendor came up with an ESB that really did remove the need to spend time on software infrastructure (and did not charge a fortune for it), then we would be interested.

I would also like our developers to settle on a "one best way" to develop applications rather than the organization investing in training and support for a multitude of programming languages and technologies. Steve advocates using the right language for the job and not being confined to one language. This is a noble cause but it is hard work learning another language and becoming proficient in it. Most developers I know have the one language that they would prefer to write everything in, just as most people I know don't communicate in anything but English. If I weren't so lazy I'd teach myself Italian so I could find out what that Italian site was saying about my blog posting. Similarly I think many developers can't realistically be expected to be truly multilingual when it comes to programming languages.

The discussion of Steve's posting gets a hijacked by the REST vs Web Services debate. This is unfortunate because the ESB discussion should be a separate issue. Using SOAP and Web Services does not require an ESB. ESBs have been conceived to assist with REST such as open source ESBs WSO2 and Mule. The more popular arrangements seem to be that Web Services use an ESB and REST does not, but this need not be the case. The REST vs Web Services argument is taken up elsewhere and in some people's minds have already been settled. Ronald Schmelzer of Zapthink states:

In many ways, however, the debate about Web services and REST is as pointless as arguing whether a hammer or a screwdriver is a better tool.

In the discussion in Steve Vinoski's posting I found myself agreeing with Jonas Ekstrom and Paul H that the ESB market is not yet mature. Jonas put this eloquently:

Religions give easy answers, but there are no easy answers. Natural selection will strike again and again until we have reached the perfect SOA.

Paul H puts a similar slant on this:

I look forward to the day when we’re in a similar stage of maturity … and there exists generally accepted, standardized, manageable, and self-federating mediation technologies … until then, we’ll all have to suffer through endless arguments along the lines of 'should I use a BEA ESB or a Sonic ESB? is an ESB really necessary, or can I get away with REST + Dynamic Languages?'

I will continue to wait until the need for an ESB (or some part of one) becomes self-evident. While an implementation of SOA can function without and ESB there seems little point in making the investment.