12 years, 1 month ago

Understanding Agility the Hard Way!

Agility is one of those words beloved by software industry marketing people. Over time it has become almost embarrassing and meaningless. Yet if you are in doubt I suggest asking Eastman Kodak, RIM, Palm, Yahoo or Nortel what they think the term means. When you don’t have agility you understand it all too well.

In today’s FT John Gapper says: Kodak’s experience has a lesson for companies in the grip of rapid technological change. As Kenny Rogers sang, “You’ve got to know when to hold ‘em, know when to fold ’em”. Unfortunately, most public companies are run by people who hate folding ’em, and instead keep returning to the shareholders and bondholders for more chips. . . . Few senior executives, when debating options for a technology company in decline, admit defeat and run it modestly. Instead, they cast around for businesses to buy, or try to hurdle the chasm with what they have got. Sometimes they succeed but often they don’t, wasting a lot of money along the way.”

It brings to mind Fred Brooks essay on software engineering. “No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. In the mind’s eye one sees dinosaurs, mammoths, and sabretoothed tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks.”

When all is going well investing for agility may seem a luxury. Why make capabilities genuinely independent so they can be switched in or out, or truly generic so they can be used in many different contexts if there’s no obvious or short term ROI? By the time you can accurately compute the ROI it will probably be too late.

Ref: Fred Brooks: the mythical man-month, Addison Wesley, 1975
12 years, 3 months ago

Let’s Kill the Confusion About Capabilities for Once and All!

I note in the Business Process Trends Advisor Paul Harmon is confused about what is a capability. What Harmon is missing is that capabilities are not just another modelling device that further helps to understand the business. Rather they are core structural concepts that allow us to establish independent units of capability. Capabilities are coarse grained business components that are inherently reusable. We define the characteristics as follows:

  • Service Oriented: Offers a software service.
  • Composite: May encapsulate all manner of behaviors including process, utility, core business (data) services.
  • Enduring: Outlives changes to how it is realized or the business processes that use it
  • Process Independent: May be used within several business processes
  • Implementation Independent: independent of how, where or by whom the capability is realized. Does not pre-empt or expose how each action is executed internally. Internal processes could therefore be changed and not impact the user of the capability service providing the contract remains unchanged.
  • Minimum Dependency: May depend upon another where a) it needs some other capability to have been exercised first or b) where there are internal dependencies. Some capabilities can be independent or self-contained. See below.
  • Measurable: Performance must be measurable

CBDI recommends:

  • whilst “not standalone” capabilities may be tactical necessities, standalone, fully independent capabilities are essential for maximum business agility, enabling replication, offshoring, ecosystem partner provisioning etc and reducing the horizon of change
  • also enabling maximum business agility, capabilities should offer a software service which is externalized, exposing the business capability to a wider world.

Harmon asks for examples. Look no further than Amazon – they offer well-formed capabilities that externalize the Amazon business such as Cloud Service; Storefront etc.

For more on this topic see the October CBDI Journal. It is free with simple registration.

Business Process Trends Advisor – Capabilities Again