The board of a large organisation appoints a CIO who delegates technical decisions to his employees. In the Enterprise Architecture (EA) department, an expert on Business Intelligence (BI) decides that the strategy for this company is to have a single Enterprise Data Warehouse (EDW). This makes sense, because experience has shown that in the long run, it is cheaper and more efficient to build one Data Warehouse, rather than start by building "islands" and then later try to merge them together.
In the mean time, some business people working for the company have rallied the budget holders, and started a project to build a new online sales application. They need to generate some reports based on the sales from this application, in order to set themselves targets and measure their performance. But, they are not experts when it comes to reporting. The business sector at which their application is aimed is cutting edge and brand new, so they don’t know what to expect, they don’t really know what kind of reports they will need, and they will certainly need to adapt to the market very quickly.
A project team in the IT department then get the assignment to build the application, including the report generation. Also knowing little about reporting, they start talking to EA, who set up a meeting, between themselves, the development team, some people from the Quality Assurance (QA) department and some experts from the BI team. Hours of discussion later, they have made the following conclusions:
- Company IT Strategy states all reporting must be implemented in the BI solution, to ensure there is only one EDW,
- The BI team are the only experts of the BI system,
- The BI team cost a lot, because they are using SAP and consultants (how many SAP guys aren’t freelance?),
- The BI team dictate a six monthly release cycle, no exceptions,
- The BI system is a black box, its inner workings stay secret within the BI team.
So, a simple question arises… "Our customer doesn’t know exactly what they want, and because of their business requirements, they need us to be agile. What do we do and can the BI team help?", the development team ask. The first answer skirts around the issue and doesn’t actually deserve being called an answer, because it doesn’t answer the question. The development team make the point that the question hasn’t been addressed, to which another attempt to avoid the question is made. Clearly, either these people don’t understand their businesses needs, or they know they can’t help but won’t admit it. Either way, the debate moves on.
Days later, the business guys are telling some colleagues about their cool new project over an espresso and a latte. "Hee hee hee, hoo hoo hoo…", laugh their colleagues. "We thought our reports would let us track our progress too, but the IT department screwed us over. They charged us double and delivered nothing useful. We tried to submit some change requests to get it working and all the IT department wanted was more money and they couldn’t deliver the changes quick enough anyway!"
The cool business dudes ran over to the IT office, informed their development team about the new information and said, "Guys, we don’t want you to use BI. Well not for the first release anyway. Maybe in a year or two. Sure, it’s policy and all, but we don’t know what we want, and need to gain some experience, so just hack those reports out within budget please!".
So the development team arrange another meeting with the
astronauts EAs and QAs to get that unanswered question answered, and they talk about the customers concerns. Even if it’s an over reaction, the point is, that another department needs to be involved meaning more communication, less visibility and hence greater costs and risks. "Sure, no problem if the requirements are stable and known, but this project needs agility", is the point the dev team makes. "Well, no, not a chance!", comes the response.
"In fact," they continue, "you simply need to go back to the business and tell them that their idea is an architecture infringement – it goes against company policies. You won’t pass QA, you won’t get the go ahead to go into production, and that’s the end of it", comes the reply.
A solution oriented response indeed… "Furthermore," continues an EA, " the business doesn’t have the right to come into our shop and tell us where to implement things and where not to. We are the experts in the technology domain. We make these choices."
Well, his argument is that the business hired the CIO, who delegated responsibility to a BI expert, who created a non-agile policy. So the business have to swallow the argument and accept that the IT department is shit and won’t give them solutions which they need, to compete in new markets… I’m not sure he realises that this is his argument, but it is, if you look at it pragmatically.
I’m not sure the cool business dudes see it that way either. I know I don’t see it that way. And I know of no solution oriented architect or developer who sees it that way.
Of course I understand the reasons we have EA, QA, Processes and Policies. For large organisations they are the only way to avoid utter chaos, amongst many other reasons. Most of my working life has been spent with large organisations, even though in many cases I was allowed to implement agile solutions. But, after a long day in the office, with some frustrating decisions, I need to rant, so here is my cynical view of EA, QA, Processes and Policies, albeit somewhat harsh: these are all things which get bigger, the larger a company is, and all things which let people hide behind their responsibility of providing the business with the solutions they need. They all cause large corporations to be compared to large dinosaurs. These departments seem to have forgotten one golden rule: if the business fails, those departments won’t exist. In competitive markets like we have today, businesses, no matter how large, need to stay competitive, and they can do so by using IT departments which are able to deliver agile solutions. These departments also often remind me of self-perpetuating witch doctors (The Witch Doctors, ISBN 074932645X). They justify themselves by stating that the business learned the hard way and now that they have been built up they cannot possibly be removed or have power taken away, like we some how never managed to go live before they existed, or that small companies can’t exist because they don’t have them.
Copyright © Ant Kutschera