Entries Tagged 'it-management' ↓

Swarm Intelligence

From the book “Honeybee Democracy” here are some cogent lessons on effective group decision making:

  1. Compose the decision making of individuals with shared interests and mutual respect.
  2. Minimise the leader’s influence on group thinking.
  3. Seek diverse solutions to the problem.
  4. Aggregate the group’s knowledge through debate.
  5. Use quorum responses for cohesion, accuracy and speed.

Top Down Procurement

Imagine you have a unique business offering that needs IT delivery and support. There are two approaches you can take to do this:

Bottom Up:

  1. Determine your business requirements.
  2. Choose an application which you think best fits those requirements.
  3. Spend a lot of money customizing the application to better fit your requirements and integrating it to other systems.
  4. Deploy the application.
  5. Hope you support the business adequately within time and budget.

Top Down:

  1. Map out the business processes to support your offering.
  2. Determine the services required to support the business processes.
  3. For services that already exist – do nothing.
  4. For new services – build or buy applications to support those services.
  5. Implement the processes.
  6. Hope….(ditto).

Often “bottom up” is the default approach, even though “top down” can be more cost-effective and provide a closer fit to your business requirements. However “top down” comes with some risk, because most off-the-shelf applications are built to support “bottom up” acquisition. You might end up having to do integration anyway.

As the world moves toward service portfolio management rather than application portfolio management, vendors move towards offering services rather than applications and the “top down” approach will become more widespread and more viable. That will be a good thing, I think.

Emergent Architecture

Dion Hinchcliffe has written a nice blog entry “pragmatic new models for enterprise architecture take shape“. This resonates well with some of the things I’ve been saying about how enterprise architecture needs to be enabling rather than blocking:

“In recent years enterprise architecture has been moving from a discipline that provides top-down, a priori technology blueprints to the business side to one that articulates key, strategic possibilities and only the most critical high-level constraints (such as security standards) and then operates as a conductor, promoter, problem solver, and evangelist across the organization through the vehicle of a cohesive community to co-develop needed solutions.”

(my emphasis added). And:

“Invariably, the best architecture I see comes naturally from self-organizing thought leaders in an organization that seek each other out and collaborate on common solutions to their problems. Rather than the us vs. them mentality of old-world enterprise architecture, there is only an us mentality. Instead of prescribed standards, designs, technologies, and tools there is real [two-way] consensus and immediate buy-in.”

And as with all Dion’s posts there is the cool graphic. I especially like the two downward facing arrows – “community leadership” and “guides”:

The article is well worth reading but I think there is a large element of wishful thinking here. It paints a good picture of how enterprise architecture should be, but I fear we are a long way from this nirvana. Much of the vision depends on a fundamental change in organizational culture. Businesses that recognise the value of an “emergent culture” will naturally have an “emergent enterprise architecture.” I don’t think it will go the other way around. Emergent enterprise architecture will not survive in or be able to change a top-down corporation.

In the long term, those companies with the right culture will support emergent enterprise architecture and thrive on IT success. Those companies that don’t will cede their IT resources to others. Those who can do IT will do it on behalf of those who can’t. Cloud anyone?

Martin Fowler on Humane Registry

I have long held the belief that governance is more about effective communication than anything else. To quoth my own horn:

…what is needed is a shared understanding of the architecture principles, frameworks, standards and best practices used within your organisation for providing and consuming Services.

How do you ensure that this shared understanding is
a) communicated effectively,
b) understood and
c) implemented by all.

A corollary of this view is that any governance tools ought to support this communication as their primary function. I’ve often thought that a wiki would make a pretty good governance tool. Good to see that Martin Fowler agrees. He describes an interesting “Human centric registry” based on a wiki with just enough automation to remove the drudgery. Martin describes the principles of the registry as:

  • People develop and use services, so orient it around people
  • Don’t expect people to enter stuff to keep it up to date, people are busy enough as it is.
  • Make it easy for people to read and contribute.

(sorry UDDI, thank you for playing).

The 10 most frequent lies told by IT consultants

From Bob Cringely, the 10 most frequent lies told by IT consultants:

1) “This can only be accomplished through a large custom development project.”

2) “Of course your data is safe.”

3) “We’ll need a day or two for optimization and debugging.”

4) “Yes, we’ve done this before. There are several companies using this product (or technology). They really like it.”

5) “Server consolidation and virtualization will save you money.”

6) “Storage consolidation and virtualization will save you money.”

7) “The upgrade (or change) will be seamless and will not affect production.”

8) “The upgrade (or change) will be transparent to users.”

9) “Yes, we tested this thoroughly before installing it.”

10) “If you install Tivoli it will solve all your support problems.”