Tag: enterprise architecture

Embracing the Technology Meltingpot

One of the most common objections I hear among my large enterprise and government clients when discussing adopting new technologies is “We’re a Microsoft shop so why would we look at a Java-based tool?” or open source, or Google, or Salesforce, and the list goes on.  This objection is grounded in the opinion that increasing the technology mix increases complexity, and thus increases the operational risk and cost.

However, the biggest challenge for IT executives has shifted from tightening their operational budgets to managing the constant risk of technologies becoming unsupported or having a vendor development path that no longer aligns with the enterprise’s needs.  The technology market is evolving and changing faster than ever.  Programming languages grow and wane in popularity and support over a cycle of just a couple of years; new frameworks breath new life into technologies that were previously left to die; acquisitions can make entire enterprise platforms obsolete overnight; and new innovations are happening constantly throughout the IT stack from networking, to virtualization, to application platforms, to business applications.

In such a rapidly changing and unpredictable environment, the best approach to managing risk (as any good investment adviser will tell you) wordleis to diversify.

In fact, any IT organization that doesn’t have an openness to innovate and investigate new technologies will ultimate die a slow death through obsolescence and operational bloat.

Instead of being afraid of the operational complexity and cost introduced by shaking up the technology stack, IT executives should be embracing them as opportunities for their teams to develop new skills and to gain a wider perspective on how to implement solutions.  Instead of remaining within the comfortable confines and protections of a given development framework, developers should be pushed to understand how different technologies interoperate and the importance of having disciplined SDLC methodologies to deal with complex deployments.

The key to success in all of this is integration.  Developing mature integration practices like modular design, loose coupling, and standards-based interoperability ensures that new technologies can be plugged into and unplugged from the enterprise without cascading impacts on existing systems.  Disciplined SDLC methodology especially around configuration management and change control allow different technology teams to work in parallel, resulting in more efficient project delivery.

IT organizations must adopt a culture of openness and curiosity to from the inevitable changes to their technology ecosystem.  They must invest in mature and disciplined integration practices to effectively manage those changes.

  • Shan
  • Gu

Prescriptive Governance Leads to Shadow IT

Let’s face it, to most people in IT, “Governance” is a dirty word.  That perception is not born out of an idea that IT governance is bad, but out of the reality that IT governance is badly implemented in most organizations.  When an organization confuses good IT governance with overly detailed and prescriptive IT governance, it starts to constrain rather than enable its people.  And when people feel constrained and not empowered to make the decisions, they work around or against the process, which then results in proliferation of shadow IT.Governance_ShadowIT

The reason for this phenomenon is that many organizations approach IT governance with a few very flawed assumptions around how software and technology projects work:

  1. Changes are bad;
  2. Consistent results are driven from consistent processes;
  3. Standardization reduces the number of decisions, which makes the process more efficient and consistent; and
  4. Measure of a good project is on-budget and on-time.
These assumptions are fatal to any IT organization because they fail to recognize the realities of the nature of technology and the people implementing it:
  1. Technology is about change.  The whole point of implementing technology is to support and enable more rapidly changing business needs.  Add that to the speed of technology changes, the default position of any good IT governance process should be to assume constant change and deal with it head on instead of trying to contain and avoid it.
  2. Speaking of change, there is no way for a one-size-fits-all process to anticipate all the different ways a technology project can unfold.  In fact, the more prescriptive a process is, the less likely it will fit the next project.  There are simply too many variables and moving targets in modern enterprise IT projects.
  3. You hired smart people to implement technology and guess what?  Smart people like to make decisions and feel ownership of their work.  By over-standardizing, talented tech resources are turned into the IT equivalent of assembly line workers.  At best they become disengaged and stale in their skills.  But more likely, they take matters into their own hands and create opportunities to make decisions or fight the governance process to retain some ownership of the work they’re being asked to do.
  4. IT initiatives exist to make your business better and the users happier.  While budget, scope, and schedule are important, they’re management measures on the process rather than whether a project was truly successful.
So how do we fix this?  In a word, simplify!  And here are some things to think about when slimming down your IT governance process:
  1. Reduce and align the number of gates to the number of “point-of-no-return” decisions on a project (e.g., business case, functional design, technical design, go-live).
  2. For each gate, focus on what kinds of decisions need to be made, guidance on people who should be involved, and some basic examples of information that should be provided as input.  Let the smart people do what they’re being paid to do, which is talk it out and own the decision.
  3. Standardize only the mundane and highly repeatable decisions.  Standards are about helping speed up the process and focusing the effort of only debating things that deserve to be debated.  It’s not about compliance metrics and enforcement.  If you have to put in an exception or exemption process, you’ve gone too far.
  4. Ensure communications on what the project will deliver in terms of functionality and value.  Most stakeholders care a lot more about whether a particular feature set is being implemented for their users rather than whether a particular deliverable is green or yellow.
In the end, this is about creating a process that helps to focus people on the real objectives of the business and fostering communications.  It’s about assuming that people are intelligent and reasonable and capable of making good decisions when given the opportunity.  And if that turns out not to be the case, it’s a HR problem and not something that should be fixed with yet more governance processes.
  • Shan
  • Gu