While it might seem a bit hackneyed to claim that yet
another major change is underway in corporate IT, a confluence of factors is
changing the way companies will deliver technology services. In the past year
or two I’ve noticed that IT is increasingly asking business users to slow down,
something that would have been relatively unthinkable five years ago.
drove technology change, dragging begrudging business counterparts along as
the CIO built the case for new technologies, development environments, or
methodologies. Increasingly, business units are demanding faster responses and more rapid adoption of new
technologies. Tolerance for long, sequential project-based work is being
replaced with demands for iterative, collaborative, and rapid development.
Consultants like myself have felt the impact of this change,
as clients no longer tolerate feasibility studies or multi-month planning
engagements, and expect to see prototypes, experiments, and minor wins in
weeks. The CIO who can adapt to this new environment will position his or her
team for explosive success, while those who fail will be pushed aside and
replaced with anyone from traditional IT consulting firms to increasingly capable
marketing and design agencies.
Most IT shops are naturally averse to risk. A poorly planned
modification to a core system can literally stop a business in its tracks.
We’ve also spent decades perfecting the delivery of massive enterprise projects
based on waterfall-style, sequential activities. Recognizing the failings of
this approach, many development organizations adopted rapid build methodologies
but these still fail to address the increasing need not just for collaboration
between the business and IT, but mixed teams of external partners, vendors, and
Adversity to risk is anathema to what our business
counterparts expect, and while it would be foolish to suggest willy-nilly
modifications to a core ERP system, rapidly iterating on mobile applications,
customer-facing web tools, and employee self-service applications is not only
acceptable, but preferred.
Let the results speak
One of the major drags on many IT-related effort is the
months spent building business cases, meeting with each and every stakeholder,
and agonizing over building the “perfect” technical infrastructure or choosing
the best vendor software. By shifting to a rapid, results-oriented style of
development, you can spend the months you would have invested in groundwork
into building a proof of concept. Some of these efforts will result in
absolutely nothing, but at the end of the effort you’ll have a far deeper
understanding of the technologies required, challenges, and impact to the business
than even the finest analysis would have produced.
The concept of enterprise IT providing various services, to
be invoked and recombined to produce new and interesting applications, is
nothing new. In the ’70s we were told Object Oriented programming was the
answer to this challenge, and more recently everything from middleware to SaaS
was supposed to turn enterprise IT into a library of components that could be
recombined at will.
While the architecture is still challenging, an emphasis on multi-client,
multi-channel applications will further the need for an enterprise architecture
that provides services and data to a multitude of devices and applications.
Rather than merely serving data, enterprise IT will increasingly provide
Application Programming Interfaces (APIs) that might serve up data and business
logic to an ERP client one minute, and Google Glass the next.
What you can do now
While this shift is not happening instantly, companies that
resolutely stick to the old ideas of waterfall development and monolithic IT
architectures that require custom interfaces for every new client will simply
Corporate IT is no longer the sole agent able to deliver
application services, with a sea of cloud providers happy to take the mantle. Start
investigating how you deliver new applications and projects. Even if you’ve
embraced a methodology like Agile, are business users and vendors embedded in
your Agile teams? Are functions like project planning and application design
embedded in your Agile process? As you change your IT infrastructure, are you
enabling a shift toward services and API-style interactions with backend
systems, or investing in custom interfaces and point-to-point solutions?
If nothing else, showing your peers that you’ve realized
that IT can no longer deliver in months or years, and must adapt to changing
expectations, will keep you, and your IT organization, relevant.