IT Architecture Meltdown - Agile is NOT the answer!

In the last post, We discussed about the diminishing role of IT Architecture in Enterprise IT.

The meltdown was mainly attributed to couple of reasons:

- Implementation/Development of Business systems are complete or consumed as a service

 (The business systems include system of records, system of transactions and even systems of engagement)

- IT costs are constantly scrutinized for business value. In understaffed and underfunded IT projects, Architecture would be the last thing that gets focused.

- Continuous Disruption in Technology space opening up a huge but uncertain canvas for experimentation and business innovation.   Experimentation / situational solutions calls for spontaneous processes.

If traditional IT architecture practices dont match up to the needs of today's requirements, what is the alternative?. Would 'Agile' help?

We have been discussing about the role of 'Agile Architectures' or 'Agile Methodologies' for coming up with solutions quickly. But, they have their own caveates namely.

- Agile methods are suited for building systems where there is uncertainity in underlying technology or uncertainity in business requirements. However, In today's times, the customers are lot more smarter. They are pragmatic, incremental and absolutely clear about their next 2-3 steps.

- Agile Architectures / Agile modeling concepts largely thrive on 'emergent architecture' patterns. The philosophy here is that 'Architecture' evolves as the business requirements evolve. Again, an expensive assumption to make in these times.

- We have also heard a lot more on 'Agile' Systems where the systems would be flexible enough to be responsive to changing business needs. This means the systems could have been over-architected to accomodate multiple unforeseen scenarious in advance. Yet another expensive approach.
- Agile methods also require the product owner to spend quite a lot of time with engineering team to continuously review and refactor the requirements and the software. All this was acceptable in a development life cycle where you have several sprints/several interim releases. Today, fully functional releases are expected in weeks not in months. So, Product Owner would rather like to spend his time with his own customers/end users than with engineering teams.

In my view, the traditional IT architecture as we know it, is dead!

If 'Agile' is not the answer, What is the next best alternative?. In my view, the next best alternative doesn't exist yet in proper shape and form and it needs to be invented/designed.

Would like to highlight some of the critical considerations for the next best alternative:

1. The traditional architecture practice focused on 'business requirements', 'static structures' and 'runtime behaviors'.    If traditional architecture is closer to 'software engineering' and 'management systems', new age architecture is expected to be closer to 'end users'. (not the sponsors)

  

2. The past decade focused on building 'systems/solutions', while today's expectation is build 'meaningful experiences'.    The 'ends' are far more important than 'means'. It doesn't mean that processes can be ignored, but they are taken for granted.   Unfortunately, We focused too much of our efforts on 'processes' in the past decade that we are poorly prepared to build 'experiences' in coming years.

The olden days architect thrived on his own technical strengths and political ability in internal organizational ecosystem. This is no longer adequate.  To be a successful architect today, it requires a lot more understanding on markets, trends, business, technology and more importantly end users and their social context.

An IT architect from past decade can morph into a new form to address these new requirements. But, We may not call him as 'Architect' anymore. Probably, a 'Service Director' or 'Experience Director'. The Director would be responsible for the overall creative outcome of the project.  I wish to see the traditional Project Manager role to morph into the role of something like a 'Production Manager' who manages all non-technical/non-creative aspects but critical for delivery such as logistics, resourcing, finances, stakeholder management etc.

In order to effectively leverage IT architecture in Enterprise IT, it is absolutely necessary to categorize/tier the systems in the order of importance as we discussed in the last post. For example, System of Records and Transactions need a lot more stable IT architecture than systems of engagement and systems that deliver experiences.

In summary, We still need traditional architecture methods and practices, but to 'maintain' our business-critical/supporting systems 'not' to address the new age business requirements.  What we need today are the frameworks, architectural processes and project management methods that would enable us to deliver 'amazing IT services & experiences spontaneously'.

Would like to stress upon some of the significant aspects of the above statement:

- We are not going to build systems and solutions - but services. Services by themselves are co-created by consumer and producer, short-living experiences.

- We live in times of plenty. To differentiate truly valuable services, they have to deliver 'amazing' experiences/results. Mere functionality is not enough.

- We need to deliver services 'spontaneously'. We should be able to deliver expected/instinctive results almost instantly.

    

Are we prepared?