Author: JP

Four Pillars: More on enterprise standards

I thought it was worth picking up on the comments made by Kris Tuttle and by James Dellow on my previous post. We’re all driving towards the same place.

First, on the reason why enterprises choose to reduce proliferation of architectures and their components, why formal standards made sense. I believe this was for three reasons:

One, procurement. You could bring purchasing power into play by selecting and standardising on one. Even if you kept a second waiting in the wings, the threat of switching was a powerful incentive for vendors to keep their prices sharp. That kind of thinking is the basis of the story of the Amdahl salesman who walked into a major buyer’s office, put an Amdahl mug down on the guy’s desk and said “There. Just let it stay there and you’ll save a million bucks”, or words to that effect.

Two, EAI. All the “big” consultants in the world were eager to tell you that IF you standardised on operating system and database and language and whatever else, THEN you would have reduced costs of application integration. They could then shift to selling data mining and business intelligence consulting while you manfully tried (and failed) to extricate your data from your systems.

Three, resource planning and hiring. By reducing the skillsets you needed, you had a better definition of the pool of people you had to have, with high resource fungibility. Then they came along and sold you the resources you didn’t have for the skillsets you were told you didn’t need. Usually augmented by arguments about “time to market” being the reason to deviate from the standards they helped you implement.
It’s always been about cost reduction. And all three reasons, if true, would have yielded cost reductions.

But unfortunately the cost reductions were hard to come by. The vendor of choice had a million ways of ensuring that you kept paying more, because you made them a strategic partner and gave them access to all your plans and thoughts and ideas. So now they could lock you in at your request and make you feel good about it. Random upgrade cycles came your way, always selling some new sizzle you didn’t need, but thoughtfully marketed to the people you gave them access to. The vendor relationship managers even went to the extent of camping in your offices at your cost, ostensibly for your own good.  And they were there to shift tin. And bodies. Owned or brokered. And they did it well.

I’ve already said enough about the resource argument and the EAI argument, both horribly flawed.

What we are discovering is that the standards are about an ecosystem, an ecosystem that is not closely held but community-managed and driven. And thankfully we are seeing such ecosystem standards emerge. That’s what I meant by the BETA generation meeting opensource.

Separately, when James mentions research reports claiming that institutions will ask employees to bring their own devices in, and the consequent challenges for IT departments, I think the answer is right but the reasoning of the research firms is wrong.

It’s not the institution who will tell employees to bring in their own devices; it’s the employees who will tell institutions that they insist on using their own devices. Stickered and personalised and skinned and whatever. [I wrote a post a long time ago about the fallacy of forcing people to use the firm’s devices, an action akin to telling people that they could only write using company pens….]

Any device you like. Wherever you like. Whenever you like. Connected whichever way you can. Everything recorded and archived and searchable. Everything open to begin with, then selectively closed to reflect real privacy or confidentiality issues, usually protected by law or regulation anyway.

Using just four classes of application: Syndication Search Fulfilment and Conversation. With a plethora of plugins and extensions from a similar plethora of sources, working within an ecosystem approach to standards, market-driven, market-maintained, community-enriched.

With the right things done in terms of identity, permissioning, authentication. Which affects our current concepts of IPR and DRM and Security and Confidentiality and Privacy. Which is why I spend so much time thinking about these things.

Four Pillars: Thinking about standards in an enterprise architecture context

In late 2004, we had quite a kerfuffle where I work, trying to decide what to do about Firefox. For sure it wasn’t the standard browser. For sure, if we blocked its use, it would not become the standard browser. So like everyone else we ummed and aahed, I spoke to my boss, and we agreed the following:

We would not support Firefox. What this meant was that no application would need to change as a result of Firefox being introduced. What this meant was that if anything went wrong, the “user” could not call up the support department and get it fixed. Firefox was unsupported.

We would not ban Firefox. People would be allowed to download Firefox, but, as per the no-support statement, they could not divert any resources towards making applications work in Firefox.

We would keep a careful eye on Firefox, reviewing matters and concerns over time. And with learning.

That’s what we decided.

Over time, as Firefox grew in popularity, it got better. The market made it better. The community made it better. Soon, I guess, it will become a standard. [And in the meantime, I will continue to play with Flock :-) ]

I’ve been thinking about this ever since that day in October 2004. And I wondered.

I wondered about standards-agnosticism. Could we start building systems that will work regardless of the “standards” in place, that are “unsupported”, that need minimal tweaking of the existing systems base, that are selected by the consumer, that are improved upon by the community, that stabilise through usage?

When Open Source meets the Beta mindset, maybe that’s what will happen. We will have more and more unsupported apps, because they work. And they improve. And they stabilise. And they don’t need supporting.

I wonder. There’s something peculiarly dissatisfying about having to change everything just in order to make one thing work. And knowing it won’t work anyway, that all we are doing is pandering to higher support costs, more lock-in points, more expensive ways of freeing up our own data.

Are standards just a euphemism for Officially Sanctioned Lock-ins?

I wonder.

Four Pillars: Thinking about enterprise architecture

This morning’s Wall Street Journal had an article headlined “It’s Not Easy Being Lean”, and reading it, I formed the kernel of this particular snowball.

In the article, a steel company called Nucor is characterised as having just three layers of management between the CEO and the hourly workers on the factory floor. And Toyota, one of the poster children for Lean, is mentioned as having at least ten layers. Separately, at least anecdotally, Google is rumoured to have a relatively flat management structure, with executives sometimes having forty or fifty direct reports. Why is this? Why does this work in some organisations and not in others?

Because layers by themselves are meaningless, it’s the level of empowerment and cohesion that matters.

What’s all this got to do with enterprise architecture? Let me posit a few “laws”:

  • 1. An enterprise IT department is a window into the soul of the enterprise itself.
  • 2. An enterprise’s IT strategy is a reflection of its business strategy.
  • 3. An enterprise’s IT architecture is a reflection of its organisation structure.
  • 4. Centralisation versus decentralisation, global versus regional, many-layered versus not-many-layered, these are all red herrings. What matters is High Cohesion and Loose Coupling, with its consequent empowerment, lack of duplication and consistency.
  • 5. These statements hold true regardless of the perceived quality of the organisation or of its IT department, in-house or outsourced. You cannot game the system.

Leadership, as per Max Depree, one of my favourite authors, is about three things:

  • Providing strategy and vision.
  • Saying Thank You.
  • And in between, being a servant and a debtor to your people. 

A firm “organises” to achieve a finite number of things:

  • Aligning execution to the objectives and strategy
  • Allocating resources accordingly
  • Using active feedback and feedforward loops to refine the allocation process in response to market stimuli
  • Having a sensible mechanism for escalation and conflict resolution

Enterprise systems and applications architectures enshrine what happens in the organisation. If there are independent fiefdoms then there will be duplicated systems. If there are meaningless control processes then there will be meaningless feedback loops. If decisions are pushed from pillar to post then the information related to those decisions will do the same. If there is no perceptible organisational strategy then you won’t find an IT strategy either. If rules are regularly broken then standards will not be adhered to either. If departments don’t collaborate then silo-ed systems are guaranteed. And so on and so forth.

If the enterprise needs investment, so will its infrastructure. If the enterprise is resilient and adaptable then this will show in its systems and application architecture. It is what it is.

So my advice is, leave other people’s best practices where they work best. In other people’s companies. Do the right thing. Do it the right way. Your systems will reflect your values whether you like it or not.

Four pillars: A toast to Beta

Many years ago, when I was working at Burroughs Corporation, we were building software for mainframes with dumb terminals. And then, as now, we would get regular complaints from “users” about the system being “slow”. [An aside: An old friend, David Taylor, recently reminded me at a conference that the term “user” now seems reserved for only two types of people, drug addicts and those who interact with computers. Does anyone know when and where the word user was first used to describe someone who “used” a computer? Or even why?]

When we investigated what the “slow” complaint was about, we found out that it was to do with response times between the sending of particular requests and the receipt of the next screen’s worth of data. So we looked at everything we could do to speed the process up. And there was very little we could do. And it was not enough.

We decided to experiment, and changed one little thing. We stopped buffering up the data for a screen’s worth, and started “painting” the screen straightaway. This way it actually took longer for the full screen’s worth to appear, but the user saw things happening “faster”. And perception ruled.

I think something similar is happening now with software. For many years people have been preaching the value of fast iteration in software development, and for many years the response has been to pooh-pooh the process. If it isn’t Waterfall and Cascade and GANTT Charted and Ten Years Late and Three Times The Budget and with Teams the Size of China it couldn’t possibly be a Real Project delivering Real Systems. There’s no space for Quiche in Programming. Perception ruled.

Now, thanks to people like Google, it’s suddenly OK to ship software with the word Beta attached to it and give it to people to use. Generation M probably haven’t seen ANY software that isn’t called Beta. They probably think it’s a buzzword for Web 2.0 (Yes I know I promised not to use that term, but nothing else will do in this case. Rules are proven by exceptions.)

We have to take this opportunity while we can. Organisation and industry DNA are already bringing immune systems to full alert, and it is only a matter of time before some great and good consultants decree that “using Beta software is a source of great security risk and global warming and anti-take-your pick”. Or much worse, they state that it is “not good practice”.

They couldn’t be more wrong. Practice it is, practice we desperately need, and for good reasons.

Software projects may fail for a zillion reasons. I won’t even bother to point you at the literature, there’s probably a Wikipedia article on Software Project Failure. Or there should be.

I believe that the single biggest reason for software project failure is mismanagement of expectations. Sometimes it’s because nobody knows the requirements well enough, so there are no expectations to mismanage. By the time there are expectations, it’s too late. Sometimes it’s because communications are poor, so expectations aren’t correctly set. Sometimes it’s because the expectation is flawed at the outset, in terms of time or cost or functionality. Sometimes it’s because feedback loops have been cut (a traditional blame-culture shoot-the-messenger environment where it is not done to talk about the impact of change). Sometimes it is just bad expectation management pure and simple.

Now we have a chance. A chance to legitimise the word Beta as part of enterprise software development. Deliver early, deliver quickly, make the fundamentals work, and allow the consumer to prioritise changes and new requirements more actively. And don’t call it fast iteration. Don’t call it agile development. Don’t call it doing the right thing.

Just call it Beta. Make as little fuss about it as you possibly can, but get it in the consumer’s hands.

By the way this is nothing new in organisations, it’s just that IT people haven’t been playing this game well. We are surrounded by draft agendas, draft organisation charts, draft presentations, draft proposals, draft contracts, draft minutes, draft accounts, draft policies, draft everything, even beer. And have you noticed that everyone thinks the work is done when the draft is issued? In fact I’m not sure all drafts go to heaven. But the customer is satisfied.

And remember, blogging is provisional. Always provisional :-)

Flight School Air: Some early thoughts

I’ve been at Release 1.0’s Flight School 06 with Sean for the last couple of days. You can read his early comments here. It was another classic Esther Dyson session, she (along with her team) has this uncanny ability to spot something important going on and then bringing together all the movers and shakers into one room quickly and easily. My thanks to Esther and team.

I don’t have a pilot’s licence, don’t own a plane, and have never invested in anything remotely to do with planes or aviation. Yet I could not stay away, because of a number of things:

One, affordable aviation, even shorthaul aviation, changes lives. I know my life has changed as a result of the availability of passenger aviation. And I believe that this mode of transport, as it becomes more affordable and more ubiquitous, can make a real difference to people’s lives everywhere. Releasing time, increasing productivity, providing timely healthcare, simplifying the process of infrastructural regeneration, allowing people to sample different lands and cultures more easily, increasing our leisure options, the list is endless.

Two, the air taxi business has a number of characteristics in common with the way the World Wide Web started, commonalities that intrigue me and excite me. I feel I am watching something important happening. More of this later.

Three, there’s real money to be made. These are amorphous times for this industry, and we need changes aplenty. Changes to the way we insure passengers, pilots and aircraft. Changes to the way we provide this segment of the aviation industry access to capital markets. Changes to the communications, navigation and surveillance systems we use for doing all this. Changes to the way yield is predicted and managed. Changes to the way we signal our interest and have our demand aggregated. Even changes to the participants themselves as they buy and sell and take over and merge and list and go private. These are heady times.

Four, much of it is about IT, yes Information Technology. Air taxis, as a concept, will serve to bring aviation into the digital world. [An aside: Have you ever been tempted to look over the shoulder of an airline assistant while your booking is being checked or amended? It is incredibly saddening to watch the hybrid greek gobbledygook double-dutch they enter into the green screens, and the machiavellian sequences of meaningless keystrokes they enter as punctuation and even screen navigation]

Five, have you ever met a child who wanted to be a lawyer? A pilot? I rest my case.

Another aside. I was sitting on the porch of the hotel in my wicker rocking chair watching the sunset over the bay, and the table next to me was taken by a set of raucous holidaymakers obviously enjoying themselves. They consisted of three generations of one family. And they were talking about how things had stayed constant at the hotel while much around it had changed. And in this nostalgic vein, someone asked the paterfamilias how things were in comparison to how he expected things to be, forty years after his children were born.

The first thing he said was that he really expected to see flying cars by the time the 21st century came along, as in the Jetsons, that the absence of flying cars was the single biggest disappointment he had had.

So why do I think there are commonalities between the World Wide Web and the air taxi business?

  • 1. The infrastructure is largely there as a result of people providing for the public good, even if defence and aerospace and academia helped make it happen.
  • 2. The operating model was that everything happened at the heart of the network, with hubs and spokes and satellites as needed.
  • 3. The people who made iteration 1 happen were infected with a sense of wonder, a sense of adventure.
  • 4. Access to the first iteration was privileged.
  • 5. All control processes were built on a very Taylorist Assembly line basis.
  • 6. It was all very capital-intensive.
  • 7. It needed a lot of collaborative cobbled-together standards and agreements to make it work.
  • 8. The whole space was surrounded by regulatory and labour implications.
  • 9. And as with the Web, the incumbents under attack were conspicuous in their absence, they had other things to worry about, a classic Innovator’s Dilemma a la Christensen in the making.

Sure, there are material differences.

  • 1. Safety and security have life and death consequences in this space.
  • 2. The regulators are more open to the changes required, and even broadly supportive.
  • 3. Unlike the incumbent telcos ten years ago, incumbent airlines are largely losing money hand over fist.
  • 4. The incumbent does not think he owns the infrastructure.
  • 5. We have all learnt from Web 1.0

I’ll post something more detailed once I’ve had a chance to gather my thoughts and to get feedback. I’ll leave you with this thought:

Watching aviation become passenger- and craft-centric, seeing the implications for communications, navigation and surveillance, understanding the nature of software and hardware and communications innovations that will happen, extending all this to new relationships and conversations and transactions, putting all this together is really exciting. It’s a market crying out for Web 2.0 models and processes. And even dreaming about how customers can co-create when you give them access to these tools is uplifting.

And this time around, we have the chance to get identity and authentication and permissioning and real-time intention and attention aggregation right. Because this time we have the learning of the past, and a compelling incentive. Getting it wrong kills people.

More later.