The approach
discussed in CIT’s Problem 5.1 puts the IT department into a specific position
and situation. These are discussed here.
The IT
department has no control over the process.
From a certain
point in time, information is available (eg as plan, objective, mismatch between
objective and operational results, complains, operational data, ..) or symptoms
or consequences (tendencies, behaviour, problems) can be noticed. The issue can
be detected. From this point in time until the submission of the demand, the
business community can act. The detect the issue early and act promptly or they
can stretch this period. The IT department is completely absent in this phase.
Random chronology
What
determines the order or timing of the demands? Unknown issues can’t be solved.
The issue must be detected. It is, in essence, this detection that is the trigger. But the detection
happens by coincidence. The timing and the order of detection of need is
completely anarchic. This order and timing can be adjusted by the moment some
critical decisions are taken and by the priorities the business assigns to the
issues. The metaphor of constructing a house can be used here. This future
house owner asks to build first the roof because it is raining. Then when he
needs to cook, he feels hungry and needs to cook. He needs a kitchen. So he
asks to build a kitchen. And so on. Houses aren’t build like that, neither are
information solutions.
Piecemeal built enterprise IT solution
The demands
can be triggered by information needs, by operational issues or by ideas of
improvements. These demands are not planned. By responding to these demands, in
fact the enterprise IT solution is built by solving one need or problem after
another. It is conceived and build piecemeal. It leads to a patchwork of
individual and local solutions (may create the need for EAI-solutions). Once
built, the local solution is integrated into the whole. Or, if it isn’t
possible, it is connected to other existing parts. It is a post-design integration,
instead of an integration by design. It is like constructing a building room
after room without having any idea of how many rooms and floors will be needed,
of how the building has to look like when it will be finished or even of the
intended size and purpose of the building. After a while, when many room are
built, one can infer what the final solution will look like. The solution grew
from the start by adding components and continuous transformation. It has never
been engineered as a whole system. Then, it might be a good idea to engineer it
to increase its qualities.
The IT
department runs after the facts
The whole approach reactive since its philosophy based
on a response to a demand.
The existence
of an issue or need emanating from the operational level is (mostly) required
to solve it. The issue must exist to be detected and before taking actions. This
is late. The issue exists already and hinders the business. They can’t or are
seldom anticipated. This creates a pressure and makes the solution
systematically to come late.
The situation is
different for needs generated by a changing environment of the business
(outside the company) or by the strategy and other plans of the business. The
business community may be direct its attention to what they are in charge of,
to those aspects they know and to the activities they will have to perform to
execute the strategy. Information needs are not really of their responsibility.
They may not pay attention at the future information needs. They have no clue
of the impact and time needed to solve them. Moreover, the change must first be
clarified and solved at the business level before being able to define the
exact information need. (This idea is not completely true.)
A demand is
submitted for a need that will materialises within 5 months. But developing a
solution in decent conditions takes 9 months. The demand has been submitted too
late. The demand should be submitted early enough to give to the IT project
that amount of time estimated by IT experts needed to execute the project.
In both cases,
the IT department responds to the demands from the business community. The
degree of reaction versus planned work depends from organisation to
organisation.
The IT
department is fully dependent of the business community
Projects are
based on the business demands. The project team tries to deliver what has been
asked by the business. This approach creates an important dependency in time
and content. It makes the IT department dependent from the business community
for an important part of its activities. The business value, the quality and
the impact on the business of the solution produced by the It department are
directly dependent of the quality of the demand and other information delivered
by the business community.
Also beyond
the demand, the business community provides the main input to the project team.
The business
community may filter information and demand.
They may want
to start with a simple and small solution or they may consider to consider only
the main case. Once this is build, they may decide to let the solution grow by
adding new requirements or features to the original demand.
What can be
filtered:
·
Features and requirements of lower priority· Aspects that are not clear yet to them
· Parts that are more complex
· Requirements that appears only as an extension of already formulated requirements
· Lesser frequent cases and exceptions
· Alternative paths
A few
examples:
- We
may start with requiring a raw text report. Later, requirements can be
added to have pictures, configurable data on the report, configurable page
layout and paging features.
- The
requirements may state to have a single-user system. Once this proved to
work, the client may ask to make it multi-user or an access from anywhere
through the web can be requested.
The business
subject matter expert may belief some information is not important and keep these
details for later. This filtered information may in the end be very important
for the design of the solution or for the choice of technologies.
The danger of
filtering is that it is done without consideration for the consequences on the
way information systems are or should be built, on the impact on the conception
of the solution.
The IT
department is last link of the chain
The whole
conception of an information solution is a process. But, and particularly with
the present approach, it can be considered as a chain. The first link consists
of the issue itself. This can be the publication of new legal requirement,
symptoms and consequences of an operational issue, the idea of an improvement,
and so on. This information must be noticed and considered by the business
community. The business community is the next link. Then information is
transferred to the IT department. They are the last link. In this arrangement,
the It department, as being the last link, always lags behind. This is not
favourable to “solve” the business-IT alignment challenge.
The IT
department is the slowest chain
The business
domain is (usually) a world at the level of the human. On the other hand, the
IT people often work at a very detailed and abstract level. Since computers
can’t interpret and decide by themselves, a huge part of the work is very
formalised. It should be complete and logically consistent. A change at the
business level can be expressed by changing a single word, adapting the
formulation of a phrase or paragraph or adding one. If an IT solution must be
adapted to such a “minor” change, this may mean work from a few minutes to
ultimately months or even years.
Conceiving
information systems is a labour intensive work. But it can’t be done well when
changes arrive at pace they can’t keep up with.
Many smaller
changes may keep the business healthy. As they imply a lot of work to adapt the
IT systems and as these adaptation are preformed under pressure, the changes
are implemented with as single goal, to have things functioning as expected.
The many changes implemented with this objective as norm, weakens the system.
Over time, it makes a mess of the IT implementation.
There are
techniques to allow a greater flexibility. Some (not any) changes can then be
implemented more swiftly. Nevertheless, the IT department is a very slow
component in the company.
This means
that it may be easier, or at least it requires lesser resource to implement a
change on the business side than to implement the change in IT. Too many
changes imposed on IT will increase the pressure in this department.
The present
approach creates a lot of obstacles for the IT department to deliver.
No comments:
Post a Comment