We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Two Views from IT on Business Process

Vote 0 Votes

Business used and uses business process for an implementation of its functionality. This fact is not a secret to people working on a business side of any enterprise. Nonetheless, IT departments of the same enterprises may be divided into two categories:

1) ITs that know about this fact and use it
2) ITs that seem unaware of this fact

It does not matter how this happens; I'll only try to enumerate some consequences to IT.

Regarding Savvy IT
In an IT, where management is aware of the role and position of business process, architects and analysts are 'hunting' for an opportunity to automate a business process, and do this for one process after another. There is a strategic motivation for such a 'hunting' - the more business processes are automated, the more of them move from business realm into technology realm. What is the value for IT in having a business process automated? It is very simple - a business process disappears after automation but the business function stays. For an enterprise, any particular process is just another implementation but business functions is the business asset - those who provide the business functions constitute a value for the corporate business. In other words, an IT providing business functions has less risks of losing its position in the company. So, the more business processes appear in the IT arsenal, the more stable position of IT is in the company.

There are only two things that can stop IT in its automation conquest:

1) If a 'business process' is not actually a process
2) A business process has steps that require activities outside of the realm of information technology.

We see examples of 'business processes' that are not processes every day; they are business Cases. Particularly, if business logic of a process is not formalised to the end and at some point a human intelligence is required to move to the next step, we have a business Case with related Business Case Management. Such incomplete business process is not a process because the 'process' outcome depends on a human intelligence, which is undefined upfront and, therefore, cannot be repeated. It is impossible to automate the process logic without applying special mathematic methods, which is a special and rare occasion.

Examples of process steps that require activities outside of the realm of information technology are everywhere. Many of us saw an improvement processes when construction workers dig holes in the middle of roads aiming to a renewal of water pipelines while new tubes were planned for this process in a couple of year time-frame and better be done off the budget of the next Government. Such things are difficult to automate.

Regarding Traditional IT
Management and developers in traditional IT organisations heartily believe that their mission is to serve business, and 'business' is defined as everything that is not IT. At the same time, people talk about partnership with their business. Those talks are not better than dreams because even a first rule of 'servant best practices' - knowing what the master wants better than the master and predicting master's wishes - is not realised by those people.

Traditional IT looks at the corporate business bottom-up, through a lens of low-level business operational activities. This viewpoint leads to adoption and domination of a tool-oriented mindset in the IT. This also becomes a stopper for the partner-ish dreams because a tool-maker may become a good vendor but not the one somebody would partner in business. There are a lot of other vendors in the market, especially in the Cloud era, and it is not obvious that the internal IT-vendor is the best.

Majority of managers in traditional IT do not know details of Business Strategic Plans and roadmaps of related architectural solutions of their organisations. Only Chief-managers might be aware of the business needs but even they think in 'project business requirements' (BR). In such an IT, business needs (so important for a partnership) are mistaken by BR as well as low-level operational business processes mistaken for the corporate business to IT developers.

Well, a tool-oriented view doesn't need any knowledge about business process' logic and squeezes IT work into an automation supporting user interfaces or into moving bulk data from data store A to data store B. Yes, an automation behind a user interface and modification of user interface's features is an important for particular operational task.

However, a requirement for any changes in the user interface or functionality underneath does not usually go through any cross-functional and cross-team analysis, no verification that particular change helps to deliver Business Strategic Plan is done, nobody confirms that the business process, which the requirement relates to, is really needed. A servant-playing IT does not dare to challenge and justify the BR. One can say that an IT is not in the position of challenging BR because, at the end of the day, business pays for the work. Yes, in many cases business pays for IT work but business is not the operational team that sends BR to IT... Moreover, in more and more industries, the business cannot make money without IT to pay IT for its work.

On many occasions, I have noticed that BR contain statements that have nothing to do with the project's objectives, which are discussed and approved by major business stakeholders. Not every word coming from a mouth of a business person is a requirement for IT, at least, it should not be. When I raised such issues with my major business stakeholders, about 30 to 50 per cent of 'BR' had been removed as unrelated. This does not mean that those statements were wrong; they simply belonged to other projects. Businesses that nurse a 'servant' role for IT usually have not their internal, inside business, controls over their decisions. I can speculate that this situation is quite convenient for such a business - if business decision appears wrong, IT can be blamed always.

Thus, I am not saying that every IT should automate all possible business processes, i.e. acquire more and more pieces of the corporate business (at least, at the level of capabilities). I am saying that if an IT has chosen a role of a servant, it has to be aware that Clouds grow a market of professional servants and a risk of being outsourced comes much closer to realisation than a couple years ago.



Website counter

1 Comment

| Leave a comment

This article is very interesting. Keep update more IT business related information. Thanks for sharing.

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives