Stuart Charlton's Blog

Stuart Charlton's Homepage
Stuart Charlton is an Enterprise Architect with BEA Systems Worldwide Consulting. Stuart specializes in the areas of architecture, REST, SOA, data warehousing, and is an avid student of lean & agile approaches to business processes and product development . Prior to joining BEA, he was the lead integration architect for a major Canadian telecommunications company, and has been a consultant and trainer for over a dozen organizations in the United States, Canada, and Japan. He is the co-author of CodeNotes for J2EE, published by Random House in 2002, and has written for leading online publications. Stuart resides in Toronto, Canada.

On Disposable Software

So I agree with Steve Vinoski's The ESB Question. Don't use an ESB if it's going to slow you down. ESBs are a decent, productive tool for SOA (and even REST!) when applied properly, but so are Python or Ruby. ;-)

<< plug >> I work for BEA, so I'm biased, natch. ESBs can be very productive, particularly in "Java or .NET only" shops, which is, well, mostly everyone large. That's because, as I said above, an ESB sometimes is really just a higher level language + some infrastructure and management capabilities.

Further, to mitigate risk & help cover complexity in large organizations, it makes sense to use a platform that is vendor supported. BEA tries really hard to make Jython supported in WebLogic and AquaLogic, for example. The whole JMX object model is scriptable, and you can do some amazing things with it. And we have PHP running on WebLogic Server. << end plug >>

What's more interesting to me is this part:

Well, ESB proponents would say that this would never do because you end up with way too many one-off solutions, while mono-compiled-language proponents would natter on pointlessly about type safety, compilers preventing errors, and performance. An assumption behind these arguments is that the integration problem being solved requires high performance, and that the solution will live for a long time. In my experience, these assumptions are rarely correct, especially the second one, since business rules change so rapidly nowadays that the integrations required to implement them change all the time as well.

But it seems the reality doesn't quite fit with this goal. What gives? Perhaps two things:

1. software has long term residual value but our investment decisions are always short term
2. we intertwingle what changes from what doesn't change

We've fixed #2 with hardware platforms. SOA was supposed to fix it for software, but perhaps not (yet).

I note that throughout my career, I've seen many fast-moving IT departments, particularly in investment banking, but even some in telecom, continue to use the "build it to throw it away" mantra with reasonable success. This works when your organization is compartmentalized. But when information sharing is of primary importance, such as the intelligence or defense establishment, for example, we get to a case where these huge organizations need a different approach. Layers upon layers of bureaucracy make it hard to abandon any pet project.

This is partly why I think Enterprise Social Computing, the Web's architecture (or some successor of REST), etc. are very exciting; they seem much more likely to strike a balance between shared agreement and decentralized execution.

Innovating beyond the enterprise

June has been fiendishly busy.

On June 14th, I presented at BEA's Canadian Exec2Exec Forum, which tends to be our biggest conference event in Canada, inviting CIOs, VPs, and Directors of IT to Taboo Resort on Lake Muskoka. The theme of my talk was "Innovating Beyond the Enterprise" -- a business-oriented view on many of the things I speak about for a technical audience on Stu Says Stuff.

My claims:

1. Businesses are changing the way they arrange processes & resources. In short, it's a move from "push" to "pull"-oriented process models. This has been discussed in many places, including John Hagel & John Seely Brown, the Lean Enterprise community, Lean Software Development, and Agile Management. Analogies of this approach are everywhere, in all human activities. Resources have evolved from being about land, labour, capital, and enterprise that are pushed through a value chain into the New Growth Theory of ideas and things that are recombined to create value and long-term wealth capacity. It indicates a move to consumer-driven approaches to organizational design, and goal-oriented approaches to resource mobilization and activity management (vs. function or process-driven).

   The point is not that "pull" is better than push -- there are plenty of cases where one wants a process to be managed for efficiency, or when demand is stable. The point, I think, is that pull models have been unintuitive or have required such high transaction costs as to be uneconomical. That's changing, due in part to SOA and Web 2.0.

2. The "service network" is evolving into a web of resources and capabilities. This term is a BEA-ism, referring to an internetwork of humans and computers, organized and governed via standard agreements, with services-orientation as a unifying metaphor and design approach.

   This is where I make a call for SOA to evolve from simple message exchanges into hypermedia. Simply put, if I pull resources, the consumer agent must be in charge of defining the application. If a registry is required to discover everything, the producer is in charge. By placing control directly into information through hyperlinks, enforcing global naming & data authority standards, and exposing a uniform interface, hypermedia drastically reduces the barrier to consume resources capabilities for both humans and machines.

   I ask the executives:

   • Why is the barrier to entry to your services so high? Why does there need to be a new project to consume a service?
   • Why can't you put your $100m unified customer profile into web browser's URL and look at it, bookmark it, tag, it, or mash it?
   • Can you create situational applications that form to meet an immediate need, do not require capital allocation, and can dissolve without pain?

   The key political insight of a web architecture is that regardless of how much automation is involved in a transaction, a human is always responsible for the outcome.

   BEA is working to address this area. The really interesting developments will be this nexus between strategy, enterprise architecture, process management, classic (component-influenced) SOA, and Web-enabled (RESTful) SOA, all of which are influencing the other's development.

3. Information assurance will be a major limiting factor. We often talk about governance -- SOA governance, mashup governance, etc. Ron Schmelzer from ZapThink claims "Just because something can be mashed up doesn't mean it should be". All of this is true, but it's just a recognition that data is political. But -- data has always been political! In my opinion, there's a lot to learn from the data warehousing and BI communities here, who have had to manage privacy, entitlement, and quality issues for fifteen years.

   The "new" governance , the one that frightens many because it integrates so many specialties, is Information Assurance, which is a multi-disciplinary approach to manage, protect and defend information from risk.
   
   

October 2007

Search this blog:

Archives

October 2007
June 2007

Categories

Recent Entries

On Disposable Software

Innovating beyond the enterprise