aqualung

Agile or plastic?

Last weekend I was reading an article on the human brain in the local dead-tree newspaper magazine insert (currently available online, too) and was struck by the concept of plasticity. In the case of the article it was particularly neuroplasticity, but my interest moved onto the applicability of the idea to organisations.

Achieving business "agility" is a hot topic in IT architecture and in management circles at the moment - that hopefully via some application of architectural thinking and some nifty software our organisation will be better placed to respond to changing business conditions, opportunities and threats. Agility is something I believe is possible with a well-executed SOA strategy for instance, but I wonder whether an enterprise architecture should be more concerned with agility, or plasticity.

In this context, what do I mean by "plasticity"? When talking about the brain, plasticity refers to the permanent and ongoing changes as a result of new experiences - as the above article suggests: my brain has been changed permanently by writing that last sentence, and yours has been changed by reading it. An organisation is not a sentient being of itself, but it is made up of humans, all with "plastic" brains - so the organisation's plasticity is potentially an aggregation of the people within it, and their changing experiences, and those individual neurological differences that impact on the work going on there.

Plasticity strikes me as being a longer-term effect than agility, which is more reactive (and not necessarily permanent). When looking at architectural abstractions, agility seems to come as a result of a tactical implementation of an architectural pattern like SOA, whereas permanent, foundational changes in the organisation's "brain" should come as a result of a more strategic and high-level enterprise model that offers an organisation the ability to continue growing and adapting over a much longer period than the next quarterly report to shareholders.

The strategic importance of the concept is this: agility won't happen unless you do something to enable it; but plasticity happens without any effort on your part - and the resulting "brain" may be sub-optimal without the guidance of a framework designed to develop the organisation into something better than it is now.

Of course, it's not a question of agile OR plastic - just as SOA can fit usefully into a more abstract enterprise architecture, an organisation can be both agile and plastic. I believe it needs to be both if it wants to last.

    

A conference for Seriously Overworked Acronyms (SOA)

This time last week I was at IQPC's SOA conference, and came away with some interesting conclusions - which may or may not hold much water, but certainly represent the impression I got over the two days.

First: there doesn't yet appear to be a considerable number of completed SOA projects in Australia - there are some well-advanced plans, quite a few smaller, proof-of-concept projects (like ours), and a few web-service-only projects.

There is also an interesting difference of opinion when it comes to justifying SOA to the board/business: some of the presenters had big, top-down plans for implementing SOA, and spoke of the business case; others took the view that SOA was a deployment option for business-sponsored projects, so there was no need to make a business case for it specifically.

My view is that, particularly in the early part of your SOA journey, applying SOA principles to approved projects may well add some cost and complexity. This extra time and expense will hopefully pay you back handsomely later - but that will be on other projects, not the one that has to be paid for now - so there's some need for a business case to justify the incremental costs incurred (particularly if the sponsor of this project is paying for something that other business units will benefit from - potentially a ticklish political problem!).

There is also the necessity for some longer-term, strategic thinking around any architectural approach - and this is where some planning is useful, especially if this is your organisation's first attempt at it. The danger of a top-down-only approach is that you spend a lot of time, effort and money and end up with a beautiful document and no service-enabled business capabilities; the bottom-up approach leaves you with too many services and no re-use, governance or agility. This is where a proof-of-concept project is useful - to test your capabilities, deliver some value with relatively little risk, and give you a practical skills/knowledge foundation from which to develop a longer-term framework.

As for my own presentation: I seem to consistently get the slot immediately before an afternoon break - which is great because I deliberately aim to run slightly under-time. That way either everybody gets an early minute for a coffee, or the reason we don't is because there is a lively Q'n'A going on. This time I took only about half my allotted period - this left time for me to ask some questions about hurdles to SOA adoption in Australia.

Well - we ended up being ten minutes late for afternoon tea, such was the discussion that ensued (almost an "unconference", an idea I suggested for next year).

Main points made:

• enterprise architects in general are hard to find
• enterprise architects with some specific SOA skills/knowledge are rarer
• someone with all that AND knowledge of the business is almost mythical in rarity - the skills shortage was identified as a potential threat to adoption of SOA

There was also discussion around the difficulty of getting the business to see the benefit of a longer-term, cross-project view of architecture and re-usable services when planning and funding is on a project basis - this is where successful PoC's can demonstrate value. The importance of governance was stressed a number of times, but a potential issue with inappropriately-applied governance stifling agility (one of the key potential benefits of SOA) was also identified.

As an aside, there was an interesting contrast between Qantas and its low-cost subsidiary JetStar, both of whom had representatives presenting. Jetstar was given a virtually clean slate for their IT, and given the low-cost objectives decided to outsource as much of their IT as possible - using SaaS applications wherever possible, decentralising responsibility for hardware, using thin clients, etc ... essentially reducing IT to a per-unit cost with minimum capital expenditure (data storage being the major exception, although if regulatory issues could be overcome, the Amazon S3 model would become attractive).

Qantas of course has more history/legacy/baggage, so doesn't have the same 'clean slate' to work with. They are also a full-service airline, so the commodity IT approach doesn't work so well. This was an organisation that appears to have taken the top-down approach to its SOA planning, starting with a fully-fledged architectural plan, implementation of SOA artefacts such as an enterprise service bus, business process management etc. - but not a great deal of delivered business capability yet.

These comments are not meant to be a judgement of either approach - there is nothing to say that both won't be successful in their respective environments ... it was just amusing to see such a difference in style between related companies.

There's definitely more than one way to skin this cat ....

Disclosure: As a speaker, IQPC comped the attendance; travel and accommodation was paid by my employer.

Technorati Tags: conference, SOA, architecture

The def:diff model again ...

  DiffDefModel3 
  Originally uploaded by ric.hayman

I actually used the def:diff model in anger at work recently, helping put together a strategy for the refresh of our viticulture and winery management systems in Aust/NZ.

For the purpose of presentation I simplified it to the ubiquitous quadrant model seen here, with generic sourcing choices for each. The boss seemed to like it ... plus he's turning into something of an evangelist for SOA/ESB himself!

I also came up with another model to help decide on implementation sequence ... I'll work it up a bit more before I publish.

How much alignment is a good thing?

A few weeks back I had an email from a Christopher Fox at Bain & Co - he'd found my blog and its topic of business:IT alignment of interest. (Aside: why email and not a comment on the blog, Christopher?)

He pointed me to an article in CIO Insight discussing some Bain research into how good (or otherwise) an emphasis on IT aligning with the business really was. The outtake: not always.

Now, I'll admit that I didn't get a clear message from the CIO Insight article - it was almost saying that aligning your IT to strategy wasn't a good thing. Fortunately Christopher forwarded me the report when it was published, and it became clearer - alignment alone wasn't worth it ... it had to be effective IT first, where "effective" is "getting IT projects up and running on budget".

The survey contrasted companies' IT effectiveness and their revenue growth (there may be an argument around the usefulness of that criteria vs profit growth or others, but I'm going with the flow) - and using the ubiquitous quadrant came up with the conclusions that the "magic" spot is to be aligned AND effective (not an earth-shattering conclusion perhaps - after the fact!). The interest lies in the contrast to the other outcomes and the poverty of an alignment-only mantra. I particularly liked the image of an "alignment trap" ... where getting the projects prioritised correctly but handled ineffectually seemed to actually make things worse.

The message seems to be that strategic alignment is important, and a worthy goal, but how you get there is at least important - get better at your project management first, and maybe the business will see the value in sharing their strategy with you.

There is a more in-depth article in Sloan Management Review that you can check out if you're interested in the survey results - it makes interesting reading (not behind a paywall when I looked last).

A tale of two conferences

As some of you know, early last week I was at Progress Technology World, a techie love-in for Progress' OpenEdge, Sonic, Actional and Apama products. Disclosure: I was there to present a customer case study of the project I've blogged earlier, so attendance was comped by Progress; we've been a Progress customer for over fifteen years, and we use Sonic's MQ and ESB products.

This week I was in Sydney for an Oracle Fusion Middleware forum - just a one day (free) set of presentations of what Oracle has in SOA/BPM/Portal stuff. We are running (what is now) Oracle's JDEdwards EnterpriseOne ERP on an Oracle database.

Now this isn't going to be a blow-by-blow technical comparison, because I'm not in a position to do so: I've used the Sonic products, but only saw Powerpoint for the Oracle stuff. The conferences were different in nature, so not directly comparable.

But (well, there HAS to be some point to this) I detected somewhat different emphases in the two events that I think define key differences in the two companies (beyond the obvious mismatch in size):

Progress Tech World demonstrated a commitment to developers - not just that there were a pile of live demos, and most presentations in the technical stream were given by practitioners (people that I've actually cut code with); but that the ethos behind it was about developing great business applications (Most companies that use Progress don't know it - they normally sell via ISVs who develop applications with the products - we are one of the few direct customers in Australia. This development emphasis is one of the reasons I think Redmonk is a great fit for Progress).

Oracle certainly has all the middleware you could ever want: Portal, messaging, appserver, ESB, BI, BPM - they've bought one of everything. They tick most boxes - WS*, JSR168, JSR170 etc. They had a good story in the presentations (though I detected some recidivism in answers to audience questions)... and it seemed to me that they are a selling organisation with development products ... and Progress is a development organisation with some products to sell.

Don't get me wrong - both companies want to sell, and neither model is "wrong" ... but there are different cultures and organisational DNA on show - and it's probably painfully obvious which I prefer! Blame it on familiarity, perhaps - or maybe credit the account manager who works hard on the relationship even when he knows our next discussion will probably mean less renewals for him.

Or maybe blame the arrogance of the Oracle VP who said "Sonic - they won't even be around in a few years!" Well the clock is on ... and I'll be interested to see if that VP is still working at Oracle then.



Technorati Tags: SOA, ESB, BPM, Oracle, Progress, Sonic

More thoughts on enterprise architecture ...

Following on from the last post, I came across (courtesy of Nick @ Toast Technology) an InfoQ article about the "partitioned, iterative" approach to EA.

Following the breadcrumbs to Roger Sessions' piece on the topic (PDF version here), I was pleased to see that the way I've approached the provision of software functionality for years actually has a name. When I tagged it for del.icio.us, I made the note that it might be "Agile for architects", and certainly the point about enterprise agility is something that Sessions plays up in the paper. Of particular note to me was that more traditional approaches to enterprise architecture were more suited to object-oriented designs (and grew out of that movement), where the partitioned, iterative model is well-suited to SOA.

My favourite take-away from it: that for so long we have been trying to create enterprise architectures to be like structural blueprints - with every detail complete; we should be looking at a more coarse-grained "city plan" for our EA, and leave the blueprints for the more fine-grained activity of business process and software assembly.

An aside: both these last two posts have been based on material from the MSDN community ... nice to know my biases aren't blinding me ;-)



Technorati Tags: architecture agile partitioned_iterative

Thoughts on enterprise architecture

archStruc1 

  Originally uploaded by ric.hayman

First, some credits: Nick Malik posts at MSDN on enterprise architecture and had this to say about the relationship between BPM and SOA; and later expanded on Gabriel Morgan's diagram about business:IT alignment to include application portfolio management

This rather ugly diagram is my attempt to summarise what they said, with a little spin of my own ...

Technorati Tags: architecture SOA BPM strategy alignment

IBM's Babushka Doll

Spent this morning at an IBM developerWorks briefing on the Rational developer tools (I won't rattle them all off - one slide identified 25 Rational/IBM development products, including the Eclipse base!) - they call the full a la carte menu a "software delivery platform" providing governance (they're topical at least), portfolio management, change/build management, and architecture management. This last was the primary focus, and  most of the discussion was around the  nested Software Modeler, Application Developer, Software Architect and Systems Developer products.

This set of Babushka dolls starts with Eclipse, and builds up layer upon layer of additive functionality (complexity?) from UML modeling, through code generation to the nirvana of model-driven development. The Systems Developer extends the modeling to hardware as well, and via a third-party plugin, uses SysML for modeling systems management.

A fair portion of the time was death-by-Powerpoint, but the two IBMers from the US (Nizam Ishmael and Ed Tuggell (? sp) - both via Austin) managed to skip reasonably lightly over the heavy ground. The demos (although necessarily a bit simplistic) were what everyone wanted to see anyway. Now, while you expect a demo to go well, what we saw seemed to showcase the model-driven architecture complete with round-tripping (the question was asked about how well this handles more complex models, but it seemed solid - experience would be the arbiter, I guess).

Also demonstrated was integration with things like RequisitePro (from which use cases could be modeled via drag'n'drop, and then finished code compared against the requirements for completeness/test cases) and ClearCase source code control.

Key phrases: business-driven development; model-driven architecture; round-tripping, SOA, Rational Unified Process

Caveat: While SOA, Web services, "agile" and Ajax were bandied about, this still seems directed at on-premise/desktop/offline applications ... it sounds like a "headspace" limitation rather than a technological hurdle.

Caveat: By the time you're a few "babushka" layers beyond Eclipse, you're starting to talk serious dollars ... mind you - there's a fair bit included: a typical Eclipse install might be 600MB - 1GB; Software Architect can be 3 times larger. Plenty of doco, RUP "mentors" every step of the way, and added functionality not (yet) available for free with Eclipse.

It was a very geeky morning ...











Technorati Tags: IBM, Rational, Eclipse, MDA, UML

Lotusphere comes to town

Lotusphere hit Adelaide today - or what was left of it after a three-week trip from Florida. I'll probably post a few more thoughts after I've digested the info a little longer, but here are some impressions:

Notes & Domino 8: client looked pretty slick, and they bragged about some stuff I'm used to seeing in Outlook and Thunderbird already. This part of the morning wasn't what I was there for, plus my (admittedly brief) experience with Domino apps in the past was not happy. For the rest of the session, the Notes client featured as a vehicle for getting to a lot of the other stuff, and that made it look very together. The new client is an Eclipse "rich client" app (branded as Lotus Expeditor) which was about the best example I've seen so far (you sort of hope that IBM could put together a reasonable demo ...).

Websphere Portal/Portal Express 6: one of the things I'm interested in. Nick was worried my next post was going to be another crack at IBM, because the supposed 45-minute install has taken over two weeks so far - but I suspect that the issue is more the environment and what was installed (and maybe not completely uninstalled) before it. Besides - IBM support don't "know" that I have WSPortal Express yet, because the upgrade order is taking longer to get processed than the software download! Back to that next week. We have been playing with the predecessor Workplace Services Express, (it's interesting to see how IBM seems to be changing the branding). The new version looks pretty good - more Ajaxy stuff, obviously good integration with the Lotus clients as well as browsers, and simpler portlet wiring. There is/will be integration with MS Office/Outlook (need to check whether it's already there or on its way). There are more templates out of the box, but team spaces are no longer a feature - mainly because of ...

Quickr: the behind-the-firewall, "Web2.0" collaboration thing. This was one of the things I really wanted to see - and I wasn't disappointed with what I saw - team blogs, wikis, document management/sharing (with versioning etc), discussion forums - none of it individually earth-shattering, but put together very nicely, with good integration with Sametime (IBM's IM) - I want to dig further into this one.

Connections: The other thing I wanted to see - the behind-the-firewall "social software" - blogs (Roller - how come IBM does more with Sun's blog engine than Sun?), tagging (Dogear), profiles; but as Cote mentioned - no apparent wiki. It WAS touted as being complementary to Quickr, so maybe that's where IBM sees the wiki - as a team-based thing, which may be valid. I recommend Steve's posts here and here for his Q & A's on Connections and Quickr ... these and Cote's post are what got me interested in the first place.

To me it seemed that the distinctions between Portal, Quickr and Connections were more arbitrary license-based considerations, rather than any significant differences at the code level. In fact I'd be very surprised if there wasn't a lot of overlap in the codebases of these products. One of the reasons for the license structure may be the large installed base of Notes/Domino and Quickplace (Quickr is the upgrade path for current Quickplace customers) that IBM doesn't want to p*ss off.

Some final things:

• This strikes me as validation for Andrew McAfee's Enterprise 2.0 meme (maybe Wikipedia will allow his article now?) and confirmation that social software behind the firewall has legs.
• IBM has effectively resurrected the Lotus brand, and provides MS Sharepoint with some powerful competition.
• While it isn't exactly open-source, IBM's use of Eclipse (which is), support for ODF, Java Content Repository, JSR168 etc. is far more "open" than say Sharepoint, because it gives customers  better options for swapping software without losing control of their data.

 



Technorati Tags: IBM, Lotus, Quickr, portal, socialsoftware, Redmonk, toasttechnology

I've unleashed a monster ...

Whe I suggested to Nick about three weeks ago that he should be blogging, I didn't think he'd take it on so seriously! Talking over coffee this afternoon, he had plenty of ideas to keep him blogging in his areas of professional interest (SOA, SaaS, portals and IT architecture) for some time yet.

One of his posts this evening touches on open data as the next frontier, and perhaps a prerequisite for further advances in open source. My own feeling is that the two, although complementary, are independent issues. It is likely that the most enthusiastic supporters of open data will also favour open source software, but I don't see any causation - it's not compulsory! The Wikipedia article on open data that Nick references suggests that it is "more oriented towards factual data and the output of the scientific research process." - I think it now means something much broader, and has more to do with co-creation of data and value from that data.Most mashups on the Web are based on freely-available data like that encouraged by the FOAF project, found on Craigslist, combined with Google Maps and generally morphed into information of more value than it originally represented.

While scientific research obviously generates and builds on the metaphorical "shoulders of giants", it will be data from all of us that will be re-combined into the "open data" that will be the next transformation  of our Web existence. It will be interesting to see how long it takes for corporates to let go of some of that "enterprise" data to generate value currently locked in their databases ...


Technorati Tags: opendata, cocreation, hortovanyi