Web Services Mixes it Metaphors

The mixed metaphor is a source of amusement and something for grammar pedants to pick upon. My favourite is from "Yes Minister", the television series written by Antony Jay (A fellow Antony with no "H").

'Minister, I have warned you before about the dangers of talking to people in the Department. I implore you to stay out of the minefield of local government. It is a political graveyard.' Bernard intervened. Just as nature abhors a vacuum, Bernard abominates a mixed metaphor. 'Actually, Sir Humphrey,' he explained confidentially, 'you can't have a graveyard in a minefield because all the corpses would...' and he made a vague explosion gesture. (The Complete Yes Minister, p. 384)

I have a beef with the terms 'Choreography' and 'Orchestration'. I do not think I am alone in having problems distinguishing the two. This is partly due to the difficulty that arises when I think of the origins of these metaphors. Full marks to whoever used some imagination to come up with new terms but the terms needs to be consistent in their metaphorical context.

According to Thomas Earl (see references below) Choreography can enable collaboration between Orchestrations. Choreography is the process of collaboration between business processes of different organisations and Orchestration is the process of organising your services within a business. So why change from music to dance as a metaphor? The choreographer who organises the steps for the dancers does not look at the orchestration prepared for the musicians. This conjures up an image of Choreographers counting to 8 (for some reason choreographers always count to 8) and musicians carrying their instruments trying to step in time. The choreographer does not direct anything the musicians do. From my experience playing in a blues band, in general, musicians can not dance. The musician is the guy who sits in the orchestra pit, or on the stage, or in the corner of the room and plays with his instrument while everyone else dances.

I think a better term or 'Choreography' might be 'Creative Direction' or 'Production'. The term needs to be something that suggests authority over the orchestration process. It is a nice touch to borrow computing terms from the arts but the industry should look out for consistency.

References
Quote from "Yes Minister": http://moksheungming.tripod.com/yes.html
The reference to Thomas Earl is from figure 6.1 in his book "Services Service-Oriented Architecture: Concepts, Technology, and Design"
Some discussion by Mark Richards on Choreography and Orchestration is provided in http://www.infoq.com/presentations/Enterprise-Service-Bus

Footnote1:
The observation that "musicians can't dance" came from Larry who was the drummer in the blues band "Sacred Blue Walrus" of which I was a member. It is generally considered that a drummer is a person who hangs around musicians, but Larry was talented musician and a perceptive social commentator.

Footnote2:
There are other differences between orchestration and choreography in the world of web-services. WS-BPEL and WS-CDL come from different standards bodies. Choreography does not have a controlling process. Choreography is more a community interchange pattern. Choreography can be dynamically extended.

The Right Stuff on SOA: Book Review Pt1

I started reading "Service-Oriented Architecture: Concepts, Technology and Design" by Thomas Earl yesterday. This is the sort of book I've been looking for in this area. It describes the theory and practice of SOA and has practical bent. Earl is not afraid to subscribe to a particular approach and explore this to the fullest.

Earl avoids some of the vagueness of the SOA term by coming up with another term 'Contemporary SOA'. He starts the definition by saying "Contemporary SOA represents an architecture that promotes service-orientation through the use of Web services". This instantly puts a clear focus on the book. It frees Earl to describe the WS-* standards in detail and means that he does not have to speak in generalities or address competing approaches to SOA.

I had for some time decided that my organisation had to move towards Web Services, not because it was the only way to do SOA but that it was generally accepted path of least resistance for and organisation with not much history of enterprise integration technologies. So I found solace in an opening quote:

"You don't need Web services to build SOA!" These are words you'll hear many say prior to explaining service-oriented architecture. However, this statement is typically followed by something equivalent to "...but using Web services to build SOA is a darn good idea..."

It does not look the sort of book that will gloss over the technical details although I have read four chapters and Earl keeps promising to get to the detail later in the book. He has covered some important territory though.

He defines "Primitive SOA" which is the more general SOA that most authors describe. He describes 19 characteristics of contemporary SOA. He discusses the Services Oriented Platform and the Services Oriented Enterprise. He looks at 13 effects of SOA and 8 benefits of SOA but keeps things real by naming 7 pitfalls.

I like the fact that he talks about SOAP, WSDL, UDDI, XML and WS-* standards. Realistically an SOA book cannot be useful to me without doing this. Earl is strong on an enterprise XML data model. He talks about the standards bodies and describes the evolution of SOA through client server and N-Tier architecture.

I have got a fair bit out of this book so far and it has wet my appetite to continue.

"Service-Oriented Architecture: Concepts, Technology and Design" by Thomas Earl comes with a companion web-site at http://www.soasystems.com/

Total Unity in Total Architecture: Book Review

I started to read "Succeeding with SOA: Realizing Business Value Through Total Architecture"
by Paul C. Brown today. I was actually looking for another book on my subscription service but the title and cover of this one appealed to me.

A number of books, articles and talks make a big point of bringing IT and the users together as if IT goes off and does its own thing just for the sake of it without consulting anyone. I have yet hear anyone say "Ignore the user, IT knows best" or "Make sure the business does what IT says". I too will sometimes gratuitously implore my technical staff to get inside the head of business but presenting the fact that IT and business should be closer is not particular new of insightful.

This book suffers a bit from this. Creating governance structures that make sure a business need is satisfied and even architectures (like SOA) that bring the business process in better view are well worth writing about and Brown spends some time on this. I found the information content thin and sometimes descending to motherhood. Perhaps this book was pitched more at the business management. There is not much technology in it. It is to be the first of two books. The second will be written for Architects rather than management. I regard myself as management and the first couple of chapters have not done much for me.

I think this book has some good points. It raises the questions

• Who from the business is responsible for the services?
• Who can provide this cross-project perspective of re-usable components?

I might persist to see what the Brown's answers to these are. I also like the steps presented:

• Justify each project on its own business merits.
• Have an explicit architecture step in every SOA project
• Have an active SOA architecture group
• Have a living SOA project road-map

This seems good advice.

In general I was looking for a more tightly written technical book. I am from a mathematical background and I like definitions precisely stated and concepts built from these definitions. Thus "Total Architecture" is not clearly defined but it is suggest that the one god-like architect is responsible for both the business processes and IT systems and we get this definition of a service "A service is a bundling of information and the functionality required to manage it".

I think I might keep looking for the book I was looking for before I found this one. I am sure I would get some benefit out of completing this one, but it was not quite what I was looking for.

ESB or not ESB?

I work for an organisation that is pretty well fixed on achieving a goal of an SOA but we are still wondering how to get there. The worst people to ask are software vendors, because the answer will always be to buy more software. This stuff costs big time though.

For the cost it took to set up our application servers I could have bought two comfortable suburban homes and then we pay the software maintenance which I have to invest in at the cost of having a couple of staff. It is not as if I can do without the staff though. I now have to recruit someone to administer the application server and find developers with the skills in this particular applications server. So when the software vendor tells me that all I need to is the pay the cost of another suburban house and sacrifice funds for another staff member to buy an ESB I need to be pretty clear that this will provide some benefit.

There is some disagreement about what an ESB is or what benefit it brings. Mark Richards looks at some of the definitions of ESB in his presentation for the NFJS conference (video clip at http://www.infoq.com/presentations/Enterprise-Service-Bus). He then defines the ESB in terms of the capabilities it might bring these are listed as:

1. Routing
2. Message Transformation
3. Message Enhancement
4. Protocol Transformation
5. Service Mapping
6. Message Processing
7. Process Choreography
8. Services Orchestration
9. Transaction Management
10. Security

If software contains about five or more of these capabilities then it is an ESB. This would normally include first three capabilities. Together Mark Richards refers to these as "mediation".

This list is handy because it allows you to look at your needs and determine whether you should purchase such a product with these capabilities. You can determine whether these capabilities are available in your application services already, whether you need to acquire a niche product to address a capability or whether you can handle some of this capability in your own code.

This list is also useful to determine what you are not getting in a particular product offering. One consultancy firm demonstrated to me a great way of addressing the routing problem in application code and claimed I did not need an ESB because of this. It was certainly useful but it will not help if I need the other nine capabilities.

There is certainly some difference of opinion on whether you need and ESB. Vendors will say you need to have an ESB to do SOA. Sandy Carter of IBM in her web presentation (http://www.infoq.com/interviews/sandy-carter-soa) says that an ESB is a a "crucial part of an SOA" and a "spinal chord of your business".

On the other hand a presentation by Jim Webber of Thoughtworks is critical of the ESB approach and believes it works against a good SOA (http://jim.webber.name/downloads/presentations/2006-10-EJA-Guerrilla-SOA.ppt). Jim claims that ESB adds a proprietary middleware to you SOA which will lock you an your software in to a particular vendor. He goes onto to say that "spaghetti" in SOA is inevitable and one of the strengths of SOA is that it copes with this. ESB on the other hand can make spaghetti worse.

One of the best quotes I found was in article by Colleen Frye discussing ESBs with Jason Bloomberg and others:

This bandwagon's a bus and ... vendors positioning in the SOA market have jumped on it over the last few years.

I don't believe my organisation is mature enough in its SOA progress to consider and ESB. We have to develop a critical mass of services before we should look at investing in more glue (as Jim Webber describes it) to organise and bring these services together.

References:

Mark Richards http://www.infoq.com/presentations/Enterprise-Service-Bus
I liked marks insight in that SOA "Presents IT Services as Business Services".
Also he mentioned a couple of open source ESBs
Mule: http://mule.codehause.org/
ServiceMix: http://servicemix.org/ (JBI = JSR-208 compatible).

Sandy Carter: http://www.infoq.com/interviews/sandy-carter-soa
Some good parts of this talk excuse her from being a vendor and almost excuse her from using the word "leverage" too much.
"ESB as a pattern of SOA."
A quote from Steve Mills "SOA will be with us for decades"
"I think that BPM and SOA are two sides of the same coin. I don't think you can do BPM without leveraging SOA."

Jim Webber: http://jim.webber.name/downloads/presentations/2006-10-EJA-Guerrilla-SOA.ppt
This is a powerpoint slide presentation. He is also promoting his book that looks interesting.

Colleen Frye: ESB Market Report, http://searchsoa.techtarget.com/originalContent/0,289142,sid26_gci1226497,00.html

Lego and SOA

Lego has been used many times as a metaphor for SOA. I first came across it during a vendor presentation and was not particularly impressed by it as I immediately saw some shortcomings in the metaphor.

After thinking about how I would explain some of the benefits of SOA like agility and loose coupling I decided Lego might be fairly descriptive after all. I ended up doing my own presentation on SOA at a planning session complete with blocks from my kids' Lego set. I felt this was one of my more entertaining presentations and it helped get across some good messages. I plan to post a transcription of the presentation on this blog. As it was a "show and tell" presentation I need to get my digital camera fixed first.

When I did this talk I did not realise the Lego metaphor for SOA was so common. Google brings up many hits that relate the two. It is sometimes handy in IT to show something tangible to explain our concepts. What we build is never clearly visible and how we build it is often very abstract.

Gian Trotta does a good job of looking at this metaphor.

These components are loosely coupled code components that represent well-defined and self-contained business services. “This is important. Loose coupling is a design criterion that enables agility. It can't depend on the context or state of other services,” she noted.

The business services become part the overall service oriented architecture (SOA). “Service-oriented architectures require well-defined interfaces and this is the evolving role of Web services. Finally, we have a standard interface that everyone's agreed on, enabling service-oriented architectures to take off,” Gold-Bernstein added.

I do not think much of the Swiss army knife metaphor though. For me SOA is not a grab bag of utilities that can be applied to any problem.

Jason Bloomberg was the source of the above illustration (which is not actually Lego, see footnote) but covers the whole Lego issue pretty well.

As with any analogy, the parallels only go so far, but with Lego blocks, we've found four positive salient characteristics -- and four negative ones

Some of Jason's points identify problems with Lego rather than problems with Lego as a metaphor for SOA. He raises the issue that Lego blocks are so unbreakable that they get passed down the generations so new generations do not buy enough new blocks. This is why the new Lego has so many different parts and looks more realistic. The Lego company is trying to get kids to build it and put it on display rather than reuse it. I see this as a strength of the Lego metaphor (or 'analogy' as Jason refers to it). This is excellent reuse but it also shows the importance of overall architecture. The architecture has adapted to meet the purposes of the business.

The physical nature of Lego means that structures are easier to break as they get bigger, composed of more building blocks. It is interesting to speculate on whether this is true for SOA. Will a big SOA implementation become more fragile? My feeling is that with good design and testing it could be fairly robust but in practice any system with more components and connections will have more points of failure.

Jason states "Lego blocks are interoperable with each other, but not with other kinds of toys." He has a very good point here. Adapters can be built for Lego. I used some sticky tape and a bit of wire attached to Lego blocks when I was demonstrating legacy adapters for an SOA. It is not common practice though to interface Lego with other toys.

Jason's last negative characteristic is "Lego blocks are for children, but children couldn't build Legoland". All metaphors have to break down at some time. SOA is not for children. Services are not made of plastic or cannot fit in an ice cream container either. The metaphorical point is that services can be composed together in an ad hoc fashion without much forethought, but to build large systems with many services that meet the needs of the business requires good SOA and discipline.

One failure of the metaphor I do think has merit is from Jack van Hoof who observes

First start building a nice fortress with LEGO blocks. Then after you finished it, just change one little LEGO block somewhere in the middle of the wall. You won't be very happy, I suppose. Not to mention creating a new window or a door. ... LEGO constructs are easy to be build, but a nightmare to be changed ...

The concern I originally had with the Lego metaphor is aptly covered by a quote from an article by Joe McKendrick who in turn is quoting a vendor white paper

But unlike a single LEGO block, which can only be used in one design at a time, a 'service' can be used by several applications at once (much like a letter in a crossword puzzle).

It is an advantage of software that it can used to process many business processes and it does not get consumed in the process. I sometimes like to consider the service is the block design rather than the actual block but I would not want to try to explain this to an audience as the metaphor starts to lose its simplicity.

The Lego metaphor has been used before in IT and will probably be used for other engineering disciplines. It is a popular model for describing why one might want to build things in parts, why we use standards and how we make big, complex systems out of simple building blocks. For me, Lego continues to be descriptive for SOA. Any discussion about its strengths or weaknesses as a metaphor just seem to help explain more concepts about SOA.


Footnote:
The image above has been presented in a number of articles by Jason Bloomberg of Zapthink. Please note that the blocks illustrated here are not standard Lego blocks. This is a photo of some other interconnecting toy. Standard Lego blocks have the Lego trademark on each of the bumps. Standard Lego blocks also have a gap between the bumps which is larger than the radius of the bumps.

References

• Totta, Gian, The Lego/Swiss Army Knife Approach to SOAs http://www.ebizq.net/topics/soa/features/4040.html
• Bloomberg, Jason, The Lego® Model of SOA, http://www.zapthink.com/report.html?id=zapflash-20061212
• Van Hoof, Jack, SOA and LEGO, do you dare to compare?, http://soa-eda.blogspot.com/2006/12/soa-and-lego-do-you-dare-to-compare.html
• Taylor, James, If SOA is Lego then decision services are Mindstorms http://www.ebizq.net/blogs/decision_management/2006/12/if_soa_is_lego_then_decision_s.php
• McKendrick, Joe, Why are we building ‘enterprise’ SOAs with ‘LEGO blocks’?http://blogs.zdnet.com/service-oriented/?p=777

LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this content.

Chasers War on Wikipedia

I went to see a live show on Sunday. The performers were Julian Morrow and Charles Firth from the television program "Chasers War on Everything". This is an Australian comedy program. Some of the clips from it have been put on YouTube and circulated around the Internet. One of their more famous clips is where they put stockings over their heads and walked into shops to see what the reaction would be to this fashion statement. Charles Firth set himself a challenge to beat Michael Moore's record of being thrown out of 34 global corporate headquarters in a month by getting thrown out of 35 headquarters in a day. You get the idea. These guys like to have a dig at the Establishment.


Julian and Charles were doing a talk as part of the Adelaide Festival of Ideas, which is a talk-fest that brings together some of the most respected intellectuals around the world to discuss the important issues, like global warming, inequality and indigenous rights. The Festival this year was subtitled "Which Way to the Future". Julian and Charles's session had a theme of new technology. It started with everyone SMS-ing questions to the two presenters and them responding. The performance was entertaining although not the typical serious material provided in the Festival of Ideas. Julian and Chas were good enough to give my kids signatures at the end of the show.

The purpose of this article is to not review their performance. This will probably done by others in the references below. I want to focus on the second part of their show which was about Wikipedia. Charles introduced the audience to Wikipedia and then proceeded to attempt to deface it by putting in spurious entries. On the Wikipedia entry for the Australian Broadcasting Commission (ABC) who is his employer, he wrote "Bunch of no-talent fascist dictators" or something similar. He made changes to other Wikipedia entries for politicians. Charles also related how he had edited his own Wikipedia entry to say something like "Charles is the greatest living intellectual on the earth" only to find that 15 minutes later he got a call from someone saying sternly "You can't do that".

My interest in this is not that it is possible the deface Wikipedia but that Wikipedia survives this type of onslaught. The ABC site and the other sites were fixed by the end of the show by a group of unseen and proably voluntary Wikipedia editors. Wikipedia is a testament to what can be achieved through collaboration throughout the world by a large group of well-meaning content providers and despite a few malevolent (albeit humorous) deeds the Wikipedia remains an amazing resource.

This point is put well by Lars Aronsson

"Most people, when they first learn about the wiki concept, assume that a website that can be edited by anybody would soon be rendered useless by destructive input. It sounds like offering free spray cans next to a grey concrete wall. The only likely outcome would be ugly graffiti and simple tagging, and many artistic efforts would not be long lived. Still, it seems to work very well"

The Wiki concept is something we have put in place in my organisation in a limited form. The software developers exchange and record information on Wiki software. It works very well. The organisation's intranet however is tightly controlled. The content management system provides the ability to have a work-flow of authorisation to publish almost anything. One person still has to authorise any content on the intranet. This I hope will change shortly. The tightly controlled nature of this information means that the information on the intrnet is not as complete or current as a Wiki might be. The sensitivity to freedom for internal content authors is curious given the Wikipedia success for a much more open content source.

References

That great picture is by Nattalia Alonso and appears on the blog John Beohm's blog http://idents.tv/blog/2007/05/. Spot the similarity with the Simpson's couch.

Chasers War on Everything Website: http://www.abc.net.au/tv/chaser/

Some video clips of Chasers War on Everything including the global headquarter record: http://www.youtube.com/watch?v=BQ344JGAUYo

Adelaide Festival of Ideas: http://www.adelaidefestivalofideas.com.au/about.html

Other blogs on the Festival of Ideas:
http://ff.moobaa.com/blog/

http://pavlovblog.blogspot.com/2007/07/adelaide-festival-of-ideas-2007.html

http://www.sauer-thompson.com/archives/opinion/2007/07/adelaide_festiv_3.php

http://www.frogworth.com/stuart/blog/?p=94

Lars Aronsson's quote was from http://en.wikipedia.org/wiki/Wiki#_note-1

Someone using Wiki for the enterprise (Spot the "bottoms-up approach"!) http://www.ebizq.net/blogs/firstlook/2007/06/scalable_wikis_made_easy_by_mi.php

The Mythical Mongolian Hordes

Following on from previous blog about M.A.Jackson another early IT writer was Fred Brooks who wrote "The Mythical Man-Month" also written in 1975. This book is dated in its title for not being gender neutral. I have never been completely comfortable with "person-months" or "staff-weeks" though. Even so, he contains some absolute gems of wisdom.

The concept of a man-month (I'll stick with this in deference to Dr. Brooks) as a unit of estimating projects implies that the more staff you put on the project, the faster it will get done. This is the myth. In actual fact the more staff you put on, the more complex the project gets and eventually you will put on a staff member who will (through no fault of her own) will make the project take longer rather than reduce the time frame. To this he adds insights like "Adding staff to late project makes it later" and "Take no small slips". If you have a project in trouble then you better change the time-frame or reduce the functionality, and do not do it in small measures.

Fred Brooks also coined the term "Mongolian Hordes" to describe the perception you could just assemble a big team and get the job done. The term comes the enormously successful reign of Genghis Kahn in building a huge empire. The suggestion that all you need is a big team is again a Myth. Even with the multitude of specialities required in a big modern development team, more people are not always the answer. I wonder at the political correctness of this term as well. I have a number of IT staff with Asian heritage, I have no knowledge of any of them coming from Mongolia but I still wouldn't feel comfortable using the term.

Some modern software does help a big team to be productive. In my organisation mainframe programmers struggle with version control. If a programmer "has" a module then often no-one else can touch that module until the thing goes into production. We are looking at version control software but the mainframe vendors charge some extortionate rates for their software.

In the mid-range space we use CVS and are dabbling with Subversion. These are both open source project and work well. A version control system is an important part of a software development environment. It allows a team to work together. One of many collaborative tools that an organisation needs to do some serious software development.

Interview with Fred Brooks
http://money.cnn.com/magazines/fortune/fortune_archive/2005/12/12/8363107/index.htm

Some references on Genghis Kahn and Mongolian Hordes
http://www.coldsiberia.org/
http://en.wikipedia.org/wiki/Mongol_Empire

'Person month, gender neutral and explicitly including the other, "better" 50 %; politically more correct equivalent to man month'
http://www.efsot-europe.info/servlet/is/167/

Subversion
http://subversion.tigris.org/

CVS
http://ximbiot.com/cvs/

The Other Michael Jackson

Once upon a time (1975 to be precise) there was a book written by M.A.Jackson called "Principles of Program Design". This was very influential and I was certainly impressed. It provide elegant design patterns that allowed program code to be developed from problems relating to data structures. It was a small handbook of how to navigate through various data structures, how to merge data structures and how to structure programs so they were easily understandable based on these data structures. It was probably the first book to publish patterns of program code. It was language agnostic so it did not matter whether you programmed in COBOL, Algol, Pascal or Fortran there were examples in your favourite language. I bought this book in its hardback edition and it still has a place on bookshelf.

I was not alone in being an admirer of this book. Jackson founded an whole methodology around his ideas know as Jackson Structured Programming. Yes, he was the original owner of the JSP acronym.

The design patterns are still relevant now, although the concept of multiple co-operating process probably makes the work on merging incompatible data structures less relevant. Today's popular design patterns have a different emphasis but it is important we do not lose the basic techniques that Jackson espoused. The important lesson from this work is the concept of design patterns. There is a pattern which is efficient and intelligible. If everyone sticks to the pattern it is much easier to follow what the program is doing.

Some of the Java EE patterns can be found at
http://java.sun.com/blueprints/patterns/

Model View Controller

I was about to write this post about the various frameworks in the Model View Controller (MVC) architectural pattern. I checked Wiki to see what it had to say on MVC only to find that the two frameworks that I wanted to discuss were not listed even though I thought they conformed to this paradigm.

The two frameworks in question are Apache Cocoon and BEA Page Flows. My organisation started down the Cocoon path fairly early in its J2EE (now Java EE) history. This seemed a good open-source product for separating the user interface, data and business logic. We seemed to be a lone voice with other government departments going for Struts, which is listed in Wiki as a MVC framework.

We moved away from Cocoon when we purchased the BEA Weblogic platform and now have adopted Page Flows as our framework of choice. Page flows is not billed as a MVC framework but provides a sufficient level of detail to easily implement MVC. That means we have another choice to make in the pursuit of our set of SOA standards and technologies. If we have settled on the Page Flow framework now we may also have to specify we implement it in an MVC fashion.

Interestingly Cocoon has separation of concerns as a clear focus although it does not claim to be MVC but does provide similar separation.

It would seem that both Cocoon and Page Flows do not dictate an MVC solution however the MVC pattern can be implemented with both of them.

MVC: http://java.sun.com/blueprints/patterns/MVC.html

Cocoon: http://www.java-source.net/open-source/web-frameworks/cocoon

Page Flows: http://dev2dev.bea.com/pub/a/2004/01/Dew.html

Cocoon and MVC: http://webservices.xml.com/pub/a/ws/2003/01/29/cocoon-xforms.html

Hype Cycle for Application Development

I recently read an article from Gartner Research (Hype Cycle for Application Development, ID Number G00147982). Generally I find the material from Gartner great. It's reasonably independent and provides the right level of detail for me mostly. It costs alot to access so you have to find an employer or university to part with the cash to subscribe. I recently heard from a vendor of mapping software that said Gartner wanted $40k to do a review of their software and include them in an appropriate "Magic Quadrant". So their independence is not absolute.

The "Hype Cycle" article was a good summary of what is happening in software development today and the relative maturity of a number of technologies, concepts and product sets. It was handy to brush up on some acronyms. ARAD SODA apparently means Architected Rapid Application Development Services-Oriented Development of Application. You can also have Architected, Model-Driven SODA. Now that seems to be putting all the current buzzwords together in a couple of long acronyms. When did 'architect' become a verb? Any way now I know that what I am trying to do at work is a SODA and, even though I quibble about the grammar, I want it to be architected.

The article itself was written by a number of contributors and provide a mix of succinct insightful writing and some marketing waffle. One of the less well defined concepts was Enterprise Information Management (EIM) which is its 'technical trigger' phase rising to a 'peak of inflated expectations'. I find EIM a little similar to Knowledge Management (KM) which in turn can be almost anything related to the enterprise. KM can be include building design, HR practices and telephone lists. It was one of those definitions that a like to ask "What is it not?" and more to the point "How is it useful?". EIM, like KM will be more an approach to looking at the whole organisation. This may bring up some useful concepts. KM seemed to spawn the concepts of tacit knowledge and explicit knowledge. Before that people talked about the "stuff in our heads" and the "stuff written down" or for the geeks "biological data stores" and "digital data stores". Tacit knowledge was a vaguely useful concept. I don't think I'll championing my organisation to do EIM.

One of the more insightful parts of this article was the analysis of SOA by Roy Shulte and Yefim Natis. I am glad to see SOA is climbing the 'Slope of Enlightenment'. Something I have been struggling with is how many services my organisation has developed. I had assumed the number was zero until one of my senior developers showed me a list of all the EJBs he had built to access mainframe data and said "look at all these services". This did no fill me confidence. In a service I expect to see late binding, loose coupling, an XML interface, some aspect of self description and the ability to integrate using business process technology. Most of the SOA definitions I have seen are pretty vague and some a clearly business focused. These did no give me the ammunition to say that this was not the type of service I had in mind. The definition added to what I had seen previously.

"An application is an SOA application if it s modular; the modules are distributable; software developers have written or generated interface metadata that specifies and explicitly contract so that another developer can find and use the service; the interface is separate from the implementation (code and data) of the service provider; and the services are shareable..."

This should give me something to work on when I say I want this sort of service. Of course I could just say I want a web services with a SOAP interface. That might be easier. I get told SOA is not just web services though.

Hype cycles have their detractors but in general these hype cycles help see the big picture. IT shops are bombarded with a huge number of technologies. We are made to feel inferior by the marketers and our more progressive staff that we are behind because we are not employing the latest tools and techniques. The bottom line though is that many of these tools and techniques are not mature. They do not actually benefit all organisations and it takes time for conservative organisations to reap any benefit from investment some products that are billed as the next big thing.

The Passion of Programming

Sometimes I think back to high school and University where programming was a passion. In my kit full of mediocre skills programming stood out as something I was good at and something I had a passion for. It's interesting to reflect on this today when I am asking programmers to be professional, to document their work properly and to follow the standards. There is passion amongst some of them. Sometimes this is detrimental and results in religious wars on technical ideologies but by and large there is not enough passion about the work. It's not like any other job. As a programmer you are building something unique every day.

I used to liken programming to building castles out of air. You create something useful from nothing except logic. It is not quite like that any more. Perhaps it never was. After all you usually needs a big computer, a powerful compiler, some noisy printers and dare I recall, stacks of punched cards and a card reader. This things faded into the environment and what really matter was logic. You seem to need much more to get started these days. Application servers, database servers, browsers, virtual machines and libraries of standard routines, classes and services. A good SOA approach is one that assembles and application from a catalogue of pre-fabricated parts. We do not building castle from air any more we are putting together with prefabricated walls, floors and ceilings, and then furnishing it using IKEA.

This is of course a good thing. We want to be able reuse what we develop and do not want to reinvent the wheel every time we build something new. The art has changed but the skill is still required, and so I hope the passion remains for many.

Like the components the human resource have also changed. There seems to be more specialties than before. I used to work for small organisations that did not really distinguish between programmers, designer and analysts. Now we can't get by without a DBA, a configuration manager, web designers, an application server specialist and a host of architects, test professionals and user support personnel.

Footnote:

Alas! "Building Castles out of Air" was not my original work. It has been bouncing around in my brain for many years first seeded there by a classic in the IT literature. After writing this blog I found the following quote from Fred Brooks' "The Mythical Man-Month". He writes it better than I.

"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination."

http://www.wordyard.com/2006/10/02/mythical-man-month/

Code Monkeys

In preparing for this blog I looked the the infinite monkey theorem on wikepedia (http://en.wikipedia.org/wiki/Infinite_monkey_theorem). It’s the theorem that goes "a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will type one of Shakespeare's great works. Apparently this was subject to a real experiment. The result was they discovered the monkey's continually typed the letter "S", defecated on the typewriters and did not produce any text of which the bard would have approved.

The relevance of the infinite monkey theorem to blogging is of course that if you keep on writing long enough at some point you might come up with something that is worth reading. This is my hope. Of course like the monkeys (and some other writers I know) I could end up getting very repetitive and using the keyboard for purposes for which it was not designed.

The term "Code Monkeys" is pretty objectionable. Writing code is difficult and exacting. If Shakespeare had to conform his works to the requirements of a compiler I suspect he would have had difficulties. Writing code no longer seems to be about sticking to the one language and submitting it to one big box that follows the instrutions. Now an application may spread over several layers using different languages and running on different boxes. This actually could be progress if it done properly. It should allow more agile, more integrated systems with more flexibility. Sometimes it is hard to convinced.

(The image of the monkey above is borrowed from a Zapthink presentation by Jason Bloomberg)

Start Somewhere

This is my first Blog entry. I'm hoping after putting this entry in I can go back later and edit or delete it. I have no idea what this going to look like but I have to start somewhere.

Blogging is one of those things that as an IT person everyone thinks I know about. But how can you keep up with all the crazy things the IT industry is throwing up? If it is not Blogs, mashing and Web 2.0 then its a host of new open standards and no-one can tell which standards are actually mature or useful.

I'm not too proud to say I started as a Fortran and Cobol programmer. There are still people in gainful employment who write Cobol. Unfortunately some are now my staff. Yes I look after a group of programmers. Most of which work on a mainframe. We are trying to update. I've now got some Java staff and a number of Sun boxes. We have got a weblogic application platform and we are trying to move forward to adopt SOA. What a struggle that is. It's got to better than programming for green screens but why isn't the path better trod? Why isn't the road to the widely accepted new paradigm as obvious as the main highway?

This blog is expected to be a fairly long lasting chronicle of a hapless and anonymous government department in its quest of the holy grail of SOA. This is going to take a while and my observation is that the goalposts change on the journey and that everyone has to find their own path - a personal journey to geek enlightenment.