Monday, March 23, 2009

Systematic Simplification

 

Systematic Simplification

When you want to find an answer to a problem, it is critical that you ask the right question.  This bit of advice is playing out in my life, yet again.

Every couple of months, I bump up against one of the core reasons for Enterprise Architecture to exist: to deliver a simpler, more agile, less expensive IT ecosystem.

And there’s the rub.  EA doesn’t deliver that ecosystem by itself.  EA is part of a larger system of business processes, some of which fund projects, some which generate software changes, and some which monitor systems and respond to incidents.  

So how can we effect this change?  That requires a systemic view of the problem we are trying to address.  To describe my approach, I’m sharing “Nick’s opinion” of the mission and vision needed to deliver on this goal.

The Simplified IT Vision: a simple ecosystem, with information that can be used where it lay, without the need for expensive processes to move it, translate it, and understand it.  Information that can be reached simply, on an infrastructure that is reliable and resilient to the peaks and valleys of normal, and even extraordinary, situations.  Support for the business that is more reliable than the business itself.

The Simplified IT mission: to manage the IT ecosystem, and the demands of the business on it, so that needs are quickly met, while the ecosystem itself becomes progressively simpler, more balanced and easier to manage.

To address these issues, appropriate goals must be set to:

  • understand the system as it is,
  • understand the factors that are driving change to it,
  • remove the sources of complexity from business processes,
  • insert the discipline of simplicity into the business of IT,
  • track progress, report results, and systematically improve.

When creating a balanced scorecard for IT, these are some of the things that need to be understood, measured, and delivered through the practice of Enterprise Architecture.

In effect, the question is this:

How can we systematically grow a simple and well balanced information technology infrastructure?

Key words:

  • “we” – As an Enterprise Architect, I take responsibility for my part, and am willing to be accountable for results.
  • “systematically” – The effect I seek must be repeatable and scalable, built in to the processes and culture of the organization
  • “grow” – I recognize that simplicity takes time and attention.  It does not come over night.  Simplicity must be nurtured and only through a long-term commitment to delivering it, can a simple ecosystem emerge.
  • “simple and well balanced” – Simplicity for the sake of itself is not the goal.  The needs of IT to own the infrastructure must be balanced with the needs of business to be able to rapidly change it.  If there is complexity in technology, let that complexity fall to the people best able to make technical decisions. 
  • “IT infrastructure” – All the talk of agile development and SOA and patterns and frameworks don’t amount to a hill of beans if, at the end, we cannot reap the benefits of what we have sown in the form of a sustaining system that is able to meet the needs of end users and business stakeholders.  We cannot stop at measuring code quality or time-to-market.  Those are good measures, but we need to go further.  We must  measure the entire system of systems: we must measure the complexity, resiliency, and reliability of IT as a whole.

Let this be the key question for Enterprise Architecture everywhere.  Let’s focus on the thing that matters and let the other stuff die out.

Alignment has effects.  What questions should you ask of yourself to insure you are aligned to a goal like this?  Here’s a list of questions to consider?

  • If you are doing a project in EA, and you cannot see how it aligns to answering that question, ask yourself: are we spending time on the right thing? 
  • Are your processes optimized to root out complexity and drive for simplicity?
  • Are you collecting and managing information that can support the difficult decisions needed to counteract years of “not looking” at complexity as the core issue?
  • Can you describe the system as it stands and describe your part in improving it, using actual measures? 
  • Are your standards worded in such a way that any system that meets or exceeds standards is a system that supports this goal?

That is the power of having a goal and describing it for everyone to see.  You can push towards a vision, measure progress, and perform the necessary work to make it real.

Posted: Monday, March 23, 2009 8:45 AM by NickMalik

Inside Architecture : Systematic Simplification

No comments:

Blog Archive