A Pile of Lamps

This posting was triggered from a conversation with Mark Masterson (available here), which sprang from topics mentioned in Tim Bray's Wide Finder blog swarm.

As we watch a fundamental shift in system architecture, migrating towards large quantities of processors/cores on single machines, many people are discussing corresponding need for shifts in programming languages, programmer skills, and techniques.

Rather than assuming computer languages and coding techniques will evolve to meet this change, it seems prudent to consider the possibility of an environment containing thousands of little SOA web services and various other LAMP-based applications.

I'm less interested in whether this is the right thing, as much as I'm interested in the possibility of anticipating it and preemptively shaping it to avoid some of the potential pitfalls.

Or as Mark puts it,

I think the great challenge for us is how to find a way to enable and allow that paradigm, as a welcome and valid part of our EA.

Is the answer a combination of LAMP, embedded computing, cluster management, and virtualization?

For its part, the LAMP stack brings an emphasis on

• HTTP-based services
  
• extensibility
  
• multiple storage models (DB and Filesystem)
• System-level containment
• Commodity components
  

Embedded computing brings an emphasis on

• Minimalism
• Asymmetrical host and target environments
• System-level packaging
• Black-box
• Minimize ongoing support
  

Cluster management brings an emphasis on

• Uniformity of management
• Holistic view of many machines
  

Virtualization provides the key to carving multicpucore machines into multiple bite-sized chunks, each providing a convenient container for a LAMP stack.

Here is a parting thought. While cogitating on the topic, I recalled a posting from Andrew Clifford. In The dismantling of IT, he postulates a simplification of IT Architecture. I mildly questioned the viability in this post, but I'm beginning to wonder if some variation of this approach is capable of providing part of what Andrew is pondering.

Quantum Architecture?

Todd Biske works through the question of Service focus or product focus? He references several articles, providing several pieces of interesting reading material.

Something occurred to me while reading through the links.

Is it possible this is another form of the particles vs. waves duality?

EOS - Elvis Oriented Architecture

In To Understand SOA, map it without technology, Joe McKendrick summarizes an interesting article by Dan North, A Low-Tech Approach To Understanding SOA.

Dan uses a fictitious 1950s company to illustrate the basic concepts. It's a wonderfully simple idea.

Dan's explanation is interesting, however, it's still a bit long for the attention span of most business people. Is distilling it down to a PowerPoint bullet list necessary to complete the transformation of SOA into a design pattern. We seem so close.

MOA - Magazine Oriented Architecture

Andy Blumenthal vents some healthy steam in SOA - Does the Emperor Have Clothes?

He's spot on with his reminder that the focus should be on alignment and relevance, not on SOA.

Once again I ponder the topic of SOA. Once again I ponder the underlying issues.

Then it hit me.

Before I go any farther, let me state for record - I believe SOA has an important place in modern IT. Having said this, it has become corrupted in/by the ecosystem.

I submit a modest proposal for resolving the current state of SOA affairs.

The proposal has two parts.

First, we should reclassify SOA as a pattern. This should help put it into a healthier context, virtually erasing the current list of issues surrounding the topic. There is little glory in selling a pattern.

I am not anti-ecosystem. In fact, I think they play an important role. To ensure the ecosystem is allowed to prosper, I propose a second part - an alternative to SOA.

Magazine Oriented Architecture (MOA)

In broad terms, it is an architectural style designed to align IT with vendors, consultants, and methodology mavens.

In anticipation of the inevitable detractors, here is a brief list of its key benefits.

• It provides a balanced solution for all invested parties.
• It abstracts several existing behaviors into one tidy architectural style.
• It is predisposed for wide scale adoption by IT
• It seems relatively impervious to ecosystem corruption
  

This is by no means an exhaustive list. I leave it as an exercise for the MOA ecosystem to elaborate as they see fit. I serve only to light the spark.

P.S. I almost forgot... I dare not take credit for the term Magazine Oriented Architecture. I'm merely reusing it. The honor of nomenclator seems to belong to James McGovern (What kind of enterprise architect are you?). I'm sure this is no surprise. :-)

SOA Isn't About Software

It's about services.

Governance Marketing

In Replace SOA Governance with SOA Marketing, Nick Malik proposes taking a different approach when motivating developments team to follow SOA standards.

I'm not completely convinced development governance can be replaced with marketing, but I'm also not convinced it's impossible. Regardless, it can significantly decrease resistance to standards.

It seems each of the categories of governance mentioned in Nick's article would be greatly simplified if marketing principles were applied. At the very least, it could help minimize a variety of unhealthy organizational reactions to governance activities. I submit that much of the burden associated with governance is related to managing the reactions to governance.