This article is Part 3 in our Information Systems series.
Part 3: How Things Should Work (current)
How Things Should Work
We recommend revisiting the goals of your major information systems and your computing environment as a whole. Consider these five basic objectives:
Data is available.
Businesses are forever finding new uses for existing data and useful opportunities to combine data in new ways. It’s impossible to anticipate all these uses when applications and databases are designed or implemented. And it’s impossible to anticipate what new data from outside the corporation will materialize and prove important. A company should be adept at gathering data from multiple sources and rapidly formatting it for analytics and decision-making. That includes extracting any and all data from legacy systems without disturbing them. Any data worth storing for one application is potentially worth exposing to others.
Business logic is available.
Similarly, the experience and logic, rules and procedures, coded into one application should be available to others. Making code available for reuse accelerates applications development because developers can modify and assemble components rather than coding from scratch. Reusing business logic has traditionally been even more problematic than making data available. The technologies for managing libraries of business rules and modules of code are in less widespread and effective use than those for data warehousing. Software vendors often don’t make the source code available, and the code is difficult to extract and work with when they do.
Interfacing is easy.
There are conventionally two basic types of interfaces, the bridges between applications and the bridges to user devices. The first are troublesome when applications have different protocols, and especially when vendors release upgrades to applications software and all the interfaces to local functionality must be revised. The second are troublesome as device types proliferate, and especially with the recent surge in mobile devices. The ideal would be an underlying architecture and set of standards that automate the development and management of all interfaces, inter-application and user interfaces alike. That’s the only way to keep pace with and capitalize on the consumerization of IT.
Change is easy.
This is the paramount goal. If data and business logic are readily available, interface management is automated, and developers use agile methods, then everyday business changes can be incorporated into information systems in record time. Conscientious employees are continuously devising business improvements, but most are implemented as workarounds because it takes too long to get them into systems. The time between a front-line employee’s good idea for a straightforward business improvement and implementation of that change should be at most a few weeks. Imagine the productivity gains of a true continuous improvement enterprise.
Experimentation is easy.
Large and potentially disruptive business changes must follow a different path: experiment with new designs in a “sandbox” apart from everyday business operations, pilot promising designs in realistic settings, scale up successful pilots, and eventually integrate into everyday operations. However, those same core assets – data, code, interfaces – should be available to enable and accelerate business experiments. With relevant assets available in a scalable cloud environment, the range of designs widens, pilots can be realistic, and big change can happen faster.
These goals are familiar to IT leaders, and they make intuitive sense to business leaders, including those with only passing familiarity with IT. Progressive organizations have been pursuing these goals for many years – but through a series of half measures and fragmented efforts, and with little help from technology vendors. Progress was limited because the technology wasn’t ready, and ambition was stifled because revamping the architecture and transforming the approach to applications management seemed too big and costly an effort. Buying inflexible software to meet most of the immediate need was always the path of least resistance.