The sharks are circling Progress
In a couple of recent posts I’ve expressed my doubts about Progress Software’s decision to divest its middleware products and concentrate on providing a cloud-based development environment. In one post, I suggested that
They’re effectively killing the middleware product value they have by announcing a slow death for them. As MWD suggests in @neilwd’s post on the topic, the sales pipeline for those products has just disappeared – reducing any revenue to PSC pre-sale, and reducing the value (and therefore the sale price) of the assets. It would have been much better to have organised the sale/spin-off prior to this announcement.
It seems PSC’s competitors can smell the blood in the water, as WSO2 announces support and alternatives for Sonic customers who may now be feeling abandoned …
forward thinking Progress customers are looking at alternative vendors, who can provide a stable, supported, and innovative middleware platform … For IT teams seeking a more robust alternative to Progress Software and looking to avoid the risk of an unknown platform future, WSO2 provides a viable path forward.
Ouch. But they won’t be the last to join the feeding frenzy …
Enterprise architecture, business design and governance.
Noticed a tweet yesterday from Brenda Michelson about enterprise architecture (EA), prompted by a GigaOm post from James Urquhart about how cloud might impact on EA:
to which I responded:
This prompted a Twitter conversation between myself and James Urquhart about the appropriate responsibilities of enterprise architects, which got to this point:
where we seemed to have exceeded Twitter’s 140-character constraint, and I decided I needed to write this post. 
First, enterprise (or business) architecture describes how a business or organisation is (or is going to be) built to accomplish its purpose. It is a three-legged stool (so every “leg” is critical):
- People: the roles, responsibilities and skills required of the people employed to achieve the business purpose
- Organisation: the values, strategy, operating model, management structure, policies and procedures, and business capabilities required to achieve the business purpose
- Systems: the business processes and supporting technologies required to achieve the business purpose.
The foundational artefacts of EA are:
- the organisation’s values (often embedded in a “values statement”)
- a definition of how an organisation is going to differentiate itself; its value proposition and competitive strategy
- its operating model (for the best explanation of this, see Enterprise Architecture As Strategy: Creating a Foundation for Business Execution, particularly Chapter 2)
- the desired business outcomes or objectives.
Collectively, these make up the organisation’s DNA, and define what it WILL do, and (importantly) what it WON’T do, to achieve the business purpose.
Just like a city, a business has several “levels” of architecture at play. The next set of architectural artefacts at the enterprise level include (not an exhaustive list, just some of the more important things):
- a model of the business capabilities (“what” the organisation does; its functional decomposition)
- a model of the high-level business processes (“how” it performs those functions)
- organisational structure chart
- policies and procedures manuals
- a technology portfolio.
Beyond that there will be more detailed functional descriptions, individual role descriptions, system documentation – other “architectural” designs at narrower, deeper levels of detail (all the way down to software code, if necessary). Critically, from the highest level of abstraction (enterprise architecture) to the lowest (writing a job description, or cutting some software code) there should be a clear relationship between the levels (a framework), so that no matter what the task, your efforts should be traceable back through all the layers, up to the business purpose and the organisational DNA. Just as they are architecturally different in nature (like the difference between a town plan, and an individual building design), they are the purview of different roles – solution architects, business analysts, organisational development specialists, etc. The work of the enterprise (or business) architect will influence, inform and occasionally constrain them, but it will be the responsibility of this different role to produce the necessary level of architectural detail.
Keen observers will notice that I haven’t delved very deeply into technology yet. The reason is simple: at the enterprise level, architecture is a business responsibility, not an IT one. While the impact on IT will be considerable, it deals with the “what”, not the “how”, and (as with all the other business specialisations in play, like HR and accounting) those lower-level decisions are left to the specialists. This is (in terms of James’ original post) where “cloud” is beginning to make an impact – it’s a solution design, rather than enterprise architecture.
That being the case, where does governance come into it? Just like architecture, there are several (related) levels of governance – I’ll concentrate on two: architectural and IT (since I suspect that this is what James’ question was aimed at).
Architecture governance is strategic and transformative in nature, and extends to decisions beyond the domain of IT. At the highest level, a company board or executive committee will make decisions on purpose, strategy, values and operating model. These are the touchstones to which all company activities should be linked. At the next lower level of abstraction architecture review boards define policies, principles and guidelines that must be complied with to ensure integrity of the business design. These will include a Technology Architecture Board (or similar) that maintains and enforces principles that are technology-related, without specifying a particular technology solution. Architecture governance is a holistic approach that requires a broad framework, such as Fragile to Agile (the framework I prefer to use).
IT Governance, by comparison, is more operationally focussed and relates entirely to IT services such as project, IT configuration, incident and problem management; and business continuity/disaster recovery planning. IT governance can be accommodated via frameworks such as COBIT and ITIL.
Follow up on Progress Software
As he promised, @neilwd sought some clarification from Progress Software Corporation (PSC) around their decision to divest most of their middleware products, and posted the subsequent update to his original post. Some of the key points (remembering that this is now third-hand):
Firstly, Bates and Smith were very clear in saying that the company needs to find a space where it can be truly different for a profitable market segment, and use this to drive growth. It’s focusing on what it calls “Application Platform as a Service” (aPaaS) and at this point, its intention is to get to be the “number 1 provider of application development and deployment platforms in the Cloud”.
My PoV: it’s a worthy goal, in an interesting (exciting, even) marketplace. There’s certainly some upside here if PSC can execute (see below for more on that).
The current enterprise IT middleware business (combining the business from Savvion, Actional, Sonic, et al) just isn’t providing enough of a growth engine for shareholders;
My PoV: I’m cherry-picking a little here, but this to me seems a key point – PSC is emphasising a shareholder view over any concerns its customers may have, which strikes me as (to use the Australian vernacular) “arse-about” if you’re interested in a long-term future (i.e. anything longer than 3 – 6 months).
and the company’s leadership also feels that Progress has struggled to focus sufficiently as it’s been fighting on a large number of fronts.
My PoV: this could be a fair point – the current PSC product portfolio is fairly broad after a decade or so of acquisitions, and may require some pruning.
My take is that if Progress can execute on the plan it shared with me, then it could do something really interesting – particularly for small and medium sized application vendors. But I also think it’s got a hell of a task ahead of it to get all these additional products – all of which are built for on-premise installation – and re-engineer them sensibly for PaaS. What’s more, because things are moving so fast in the PaaS world, I think its window of opportunity might prove very tight to squeeze through.
My PoV: Aha! the execution problem rears its ugly head – this was my initial reaction … the new products don’t actually exist yet, or at least not in the required form for this strategy – how long will it take to get to market in any sensible shape? This makes the whole announcement sound like a premature exclamation; both the new product development AND the divestment strategy should have been further progressed before making it.
Secondly, although Progress plans to divest the product businesses as laid out above to help it focus much more clearly, it’s currently looking at ways it can continue to make use of some of the Savvion technology in combination with OpenEdge – so it can continue to offer what it currently calls OpenEdge BPM (particularly of interest to its ISV partners).
My PoV: Oh oh … now we’re getting mixed messages, and muddied waters. Do they want to divest the middleware kit, or not? How would any cross-licensing/partial carve-out of functionality work, and how much does that affect the value of the middleware assets?
the company is prepared to go on record to say “While [the] intent is to divest the Savvion (BPM) and Sonic (ESB) products, [Progress is] committed to supporting features that are essential for building and deploying agile, next generation applications.”. This is something that anyone interested in the future of OpenEdge needs to watch carefully.
My PoV: more mixed messages – at this stage I would guess that any potential purchaser of the middleware products is getting confused, and possibly walking away.
Third, Progress is going to try to find buyers for its divested product lines as soon as possible; it understands that while there’s uncertainty in the market about what will happen next, those businesses could very easily freeze. Its business plan does assume some short term revenue decline as part of this strategy shift, but my view is that nevertheless Progress needs to work very quickly and diligently from here on
My PoV: agree completely; in fact I’d go further and suggest that these product lines may already be dead in the water, or at least drastically written down by the marketplace. I hope I’m wrong, for any number of reasons, but … Neil’s
advice to any nervous customers using the to-be-divested products is to keep a very close eye on where those products go. Your strategy could be affected if a key technology you rely on ends up being owned by an outfit primarily concerned with milking maintenance revenues.
… or someone with a competing product, in which case they could disappear without a trace.
Again, while I appreciate that PSC has some disclosure obligations around share price-sensitive information, this seems half-baked. This additional information does nothing to alleviate my original concerns, and adds some ambiguity around PSC’s continued use of some of the middleware in its new direction. I also see no compelling argument for the divestment other than PSC’s lack of confidence in its own ability to execute on the PaaS play while hanging on to its existing portfolio, and I see a very unsettling effect on customers at a point when they really need to keep customer belief high.
In short – I like the new direction; but don’t think product divestment is necessary to accomplish it. I DO think the divestment, and the way it is being handled, damages customer relationships (damage that will linger) in favour of shareholders (who will have forgotten all about it in a month’s time).
Enterprise Architecture vs Social Business
[A long-overdue post on the New Enterprise]
I’m deeply interested in the potentially disruptive effects of “social media” on the enterprise as we know it.
I’m also an enterprise architect – into governance, imposing some discipline, big-picture strategy, technology roadmaps, and the like.
How do I reconcile those two interests?
Some context:
Harold Jarche speaks about some of the changes in work in the 21st century, and notes that knowledge and learning in enterprise are now group pursuits, because …
Individual learning in organizations is basically irrelevant because work is almost never done by one person. All organizational value is created by teams and networks. Furthermore, learning may be generated in teams but even this type of knowledge comes and goes. Learning really spreads through social networks. Social networks are the primary conduit for effective organizational performance. Blocking, or circumventing, social networks slows learning, reduces effectiveness and may in the end kill the organization.
Sounds disruptive, and it can be, especially for businesses still mired in Taylorist thinking, seeing one right way of performing jobs, and the incumbents as fungible and replaceable resources. But some proponents of Enterprise2.0/Social Business forget the alligators/draining the lake problem – before you can get Enterprise2.0 working, you need to have sorted out Enterprise0.0 and 1.0, or you will be too immersed in those problems to make the cultural changes required.
Enterprise 2.0 needs the “earlier” layers to be sorted, as Alan Patrick suggests:
- Enterprise 0 – the non IT stuff – the processes, skills and culture of a company – the bedrock layer – will scupper any attempt to add higher layers if it isn’t a strong enough foundation. In all our work we have found you have to strip back to the processes and skills as a minimum.
- Enterprise 1 – the ERP, CRM, EDI, SOP and all the other TLAs that manipulate, manufacture and move base information around the enterprise. If the underlying data is crap, and the ability to see it correctly is non existent, then the Social Business layer will fail.
- Enterprise 2 – as in the supporting Web 2.0 systems that support the Social Media modules – crap webpages, poor real time performance, inflexible CMS – these are only as good as the systems they sit on top of.
Which seemed to mesh with a presentation from Dave Allen (the Getting Things Done ® guy) about the whole GTD thing: it’s not actually about “getting things done”, it’s about freeing up cognitive space so we can do more interesting things. Now GTD is at the individual level, but the same principles hold true at the enterprise level: enterprise architecture (EA) is about making sure that the background stuff stays there, and allows an organisation to concentrate its collective cognition on the functions and capabilities that make it different and better and agile and a whole lot of other goodness (fill that in with whatever your organisation sees as important). One way of finding and focusing that cognition is to use social networking tools to surface and amplify it.
But if you’re too busy trying to balance the general ledger, you won’t have time to figure out what new changes are on their way, and how you might adapt to them … so EA is like GTD for companies.
Interesting stuff from April 20th through April 26th
The periodic round up:
- How Zynga, Facebook and Groupon’s Go-To Auditor Rewrites Accounting Rules – Forbes – An article interesting on two levels: it raises some questions about pre-IPO financial advice and post-IPO audit deals; and it also raises some interesting questions about how we account in the real world for financial transactions played out in a virtual world. One for the accounting wonks out there …
- Journalism Inside® – While we may have outgrown the need for dead-tree newspapers, we will continue to value the practice of journalism (even if we don’t call it that in the future). Jeff Jarvis explores some possibilities for the future of journalism …
- The Myth of Social Media Tactics Versus the Reality of Social Business Strategies - A gentle reminder that having a Facebook page doesn’t make you a social business – tactics bereft of a strategic framework will amount to very little. Creating (or transforming into) a social business often requires a cultural shift, and this needs more than ticks on a checklist of social tools.
- Game-change: Moneyball and the reality of social business - So, you thought Moneyball was a movie about baseball? Wrong … it’s a morality tale about YOUR business, and how outdated business models are killing you, and all you can do is sack the people who tell you that. Will you be playing in your industry’s equivalent of the World Series, or will your season end prematurely? Start listening to the folk who are telling you things you don’t like to hear, because they don’t fit your current models … pioneer or dinosaur?
- Ten graphs on organisational warfare – A fairly deep look at (and great synthesis of) models of business competition tied together as an explanation of how organisational warfare is conducted, and why business can be complex.
Progress Software Swaps Middleware for Vapourware
In a recent press release, Progress Software Corporation (PSC) announced a changed strategy, in which they intend to refocus on their original database and software development tools, and drop what are now considered “non-core” products (notably the Actional, Savvion and Sonic brands).
This at a time when middleware, especially BPM and ESB/SOA, has finally exited the hype phase and actually started seeing worthwhile application in business settings. The new Progress focus is on cloud development, positioning themselves as
“a leading provider of a next-generation, context-aware application development and deployment platform in the Cloud for the Application Platform-as-a-Service (aPaaS) market”
It should be pointed out that this is a shift from great middleware products with an excellent track record, to products that, while the components may exist, are otherwise not currently available.
The move seems to be the brainchild of new CEO Jay Bhatt, and seems to reflect his background in software applications at Autodesk Inc, the AutoCAD people. I have a couple of problems with the idea:
- It’s a risky (and “fashion-driven”?) play into the cloud arena. By itself, that’s not necessarily an issue (I think there is considerable potential there, and it certainly leverages Progress’ heritage in software development and deployment), but it is a start-up playground, and PSC may not have the mindset or the lack of constraints that a garage band does.
- They’re effectively killing the middleware product value they have by announcing a slow death for them. As MWD suggests in @neilwd’s post on the topic, the sales pipeline for those products has just disappeared – reducing any revenue to PSC pre-sale, and reducing the value (and therefore the sale price) of the assets. It would have been much better to have organised the sale/spin-off prior to this announcement.
I will confess to a little personal angst, too: I’ve used most of the Sonic kit, and have a high regard for the Savvion product, and I suspect that they will now be an example of excellent products lost in the sea of mediocrity sailed by big-box purveyors …
