Cognition 2.0

Many organizations have faced the challenge of making IT assets deliver real value to their business. As new technologies enter the market, companies and their IT departments have to consider the implications of adopting them in terms of risk and business value. Sometimes this effort is so complicated and involved that it takes away precious resources that are allocated to real projects and are subject to delivery schedules. In this blog I would like to challenge the process by which corporations are able to make the adoption of new technologies part of their standard governance process and will attempt to frame it within the scope of various levels of maturity of architecture practices.

We have all witnessed or been part of an organization where certain standards are in place, but nobody seems to follow them, let alone enforce them. We all assume it's the project manager that is accountable for the success of the project, but PMs are rarely concerned with the technical details of the deliverables. They are there to ensure the project comes to an end within certain constraints that were given to them around budget, time, and quality... PM 101.

On the other hand there are the technical leads and architects that are part of the technical team and oversee the technical aspects of delivery, including software design, methodology, coding standards, code environmentalism (reduce, reuse, recycle), and the adherence to certain architecture principles and patterns that will make the solution more reliable, simpler, and scalable. Their interaction with the PM is frequent and very important, in order to keep track of progress and any risks or issues that may put the project in jeopardy.

However, this picture is only one of many, perhaps even hundreds or thousands, individual projects happening at the same time and within the same organization. Each project and team is performing the best possible effort within the same boundaries and with the same kind of responsibilities as the ones outlined above, but there is no guarantee that all these efforts are yielding a coherent and cohesive picture for the enterprise as a whole. There isn't an overarching body that insures that the 35,000 ft. picture of the enterprise is shaping up as planned, nor that it is providing the business benefits that the organization as a whole is steering towards. Furthermore, the enterprise is part of an industry that itself is moving in a certain direction, and this direction is also important for the enterprise.

We have all heard and perhaps even used Agile development methodologies that deliver early and constant functionality to the business stakeholders, but, as dynamic and pleasing as these methodologies may be, it is easy to veer away and stray from the final objective. Agile methodologies provide an adaptable software development process that easily accommodates new requirements or changes, however the focus of each iteration has a short-term vision, whereas the outcome of the project has to satisfy a long-term vision. This difference in vision scopes are the source of project failure and expensive re-work and its consequential budget impacts.

So, in order to deliver value to the business, not only a constant stream of functionality must be delivered, but a steering body needs to be part of the process that constantly aligns and reconciles the short-term vision of software delivery with the long-term business goals and principles. It's like having a boat with several oars and people rowing, but there must be somebody that steers the boat and keeps constantly an eye on the destination or vector that they are sailing on.

Here comes the question: who is best suited for that task? In your experience, how were short and long term visions proactively managed and implemented?