Category Archives: Strategy

Thoughts on corporate and IT strategy

If enterprise architecture is the answer, what was the question?

You’ve heard the term “enterprise architecture”, and maybe you’ve been told it’s something your business should be looking at. But you’re not sure what it is, or worse – you’ve heard several different (and probably conflicting) explanations for it.

That’s possibly because when we are asked about enterprise architecture, we launch into a description of what it is and what it produces … in other words we talk about features. This is despite all the indications and exhortations that customers aren’t looking for features, they want to know the benefits; or “what’s in it for me?”.

That can be hard at times, because the benefits are dependent to a large extent on the problem, i.e. I don’t know what the answer is until I know the question. So what are some of the questions that businesses often ask that enterprise architecture can help provide an answer for? Here’s a few I came up with; you might recognise some of them:

Change: how do we handle change, whether we’re making it ourselves or it’s being imposed on us by the business environment?

Business design: how can we improve our business design – how we structure it, how we compete, how we manage it.

Investing: how can we ensure that we invest to our best business advantage?

Management conversations: how can we ensure that internal management discussions use a common language and understanding of the business?

How do we know we’re getting value from our IT investment?

 

 

More about achurch & associates 

 

Are we getting value for our IT investment?

[One of a series of posts posing questions that enterprise architecture can answer]

Understanding the business intent, defining the business capabilities and their boundaries and using those foundations to draw up a roadmap of projects to go from the current state to a preferred future will all contribute to confidence that the new investment your business makes in technology will give the desired results. 

Fragile to Agile’s Integrated Architecture Framework contains two things that help:

  • a framework for prioritising the identified roadmap projects to achieve your most important strategic improvements first, and
  • how different technology layers are defined, and how those definitions lead to principles that govern the provision of technology, like building codes for the construction industry. These principles, combined with an Architecture Governance Framework, can create a permanent supervision of technology implementation that builds trust in the value of IT over time.

These frameworks can give traceability of each technology initiative (right down to software coding) all the way back up to the business intent that is the starting point of our enterprise architecture path. They are the “town plan” that ensures that whatever you build, it matches your intentions, aspirations and principles.

  

If you’d like to talk some more, contact us.

 

Other questions in the series:

Change: how do we handle change, whether we’re making it ourselves or it’s being imposed on us by the business environment?

Business design: how can we improve our business design – how we structure it, how we compete, how we manage it.

Investing: how can we ensure that we invest to our best business advantage?

Management conversations: how can we ensure that internal management discussions use a common language and understanding of the business?

 

 

Red Hat to acquire FuseSource from Progress Software – Yahoo! Finance

Red Hat to acquire FuseSource from Progress Software – Yahoo! Finance

“… it has signed a definitive agreement to acquire FuseSource from Progress Software(PRGS). FuseSource, a provider of open source integration and messaging, will enable Red Hat to accelerate the delivery of application integration products and services

First news of action on Progress Software’s plans to divest (mainly) its middleware assets. This sounds like good news for the FuseSource gear; Red Hat is the poster child for “commercial open source” and this will fit with some of its other products. 

From the Progress side of the deal, this represents a good start on the divestments, albeit NOT the jewels … I’m still sceptical of the likely outcomes for the Sonic products. Happy to be proven wrong, but I still think this is a strategy designed to appease shareholders, not customers.

Previous posts here and here … it would probably pay to keep an eye on @neilwd for a follow-up to this post.

 

 

m4s0n501

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:

heading to @ #FEAF12 today. Curious to #entarch crowd reaction to @ (rightly) poking the EA box - http://t.co/OMuR3HII
@bmichelson
brenda m. michelson

to which I responded:

@ My first reaction: what @ calls EA I describe as solution architecture/system design; see http://t.co/hOqjVLs2
@achurchassoc
Ric Hayman

This prompted a Twitter conversation between myself and James Urquhart about the appropriate responsibilities of enterprise architects, which got to this point:

@ @ OK with that as well. Not all EAs seem to think that, however. Where does governance fit into EA?
@jamesurquhart
James Urquhart
@ @ 1. Then I'm not sure they're EAs :) 2. will have to address governance in a blog post - needs more than 140 char
@achurchassoc
Ric Hayman

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:

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).

 

 

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 …