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?

IT Architecture Meltdown - Are we prepared?

If you are an IT Architect, Am sure you must have come across a similar situation in your career..

Few years ago, in my previous company, I used to lead Architecture practice. During those days, One of the senior program managers came to me asked - 'Bala - As you know, We are developing this application for an internal need, do you think we need to go all nine yards in Architecture?. Is it even worth it?. Can we do it in some scripting langauges like cold fusion? Would that suffice?'. My answer was a resounding 'Yes'.

In most of the unstructured scenarios where a new custom application gets developed, it may be worthwile to watch out for following scenarios:

- The so called new app may be for a non-critical internal business need
- The app may be an interim arrangement till a suitable solution becomes available in the company / market.
  For example, most of these custom apps may get replaced by a huge ERP or a cloud service or COTS package in near future
- The underlying business process itself may be temporal / short-living in nature
- The app can be an 'early-bird' experiment in a specific technology - for example, a mobile application for a specific platform.

In all these cases, the app is not expected to be built for durability. I would like to stress the word 'durability'.
Durability calls for high-commitment, high reliability, huge upfront costs/investments, plan for future support (example - versioning). In short, durability means 'built to last'.

In the absence of durability, we are referring to a low-touch, low-commitment application. You may say, it may of of low-quality.  And Customers are perfectly fine with that, purely because of the fact that those apps are not expected to be durable.

Only when you build a highly durable software, you will need the 'Architecture'. Having a robust architecture will address all the non-functional requirements of the software.

In my view, we are at the 'tertiary' phase of Enterprise IT applications, where the core apps that form the foundation & custom apps that form the differentiation were all built in the last few decades. We have now entered in to the decade of discontinuities where architecture multiplicity has become the norm, not the exception. Business is flooded with abundant of choices in disruptive technologies with their own architectural choices - be it mobility, social media, cloud and analytics.

And We live in highly uncertain times where predicting the business climate for next few months itself has become a huge challenge. For the first time in many years, Indian IT services company Infosys has suspended its quarterly revenue guidance, owing to uncertainities across its global customers across many verticals.  In those conditions, businesses are forced to take tactical, incremental and sometimes non-durable/experimental steps to sustain and grow the business. Of course, not to mention with least upfront costs. In another story, most of the IT outsourcing companies are holding around hundreds of thousands of people on Bench - without utilization - due to decline in demand.

In times where just-enough functional outcomes are valued lot more than durable qualities, Architecture would be underutilized. If done in force, unvalued by the business.

And that is exactly happening in the industry right now - be it Enterprise IT or outsourcing / IT services industry.
For Architects who have not come to terms with this reality, finding themselves misplaced and misunderstood. And businesses end up underutilizing Architecture in places where its not appropriate.

The whole reason that triggered me to write this post was an article on the traditional civil architecture called - Architecture Meltdown - that talks about the fate of building architects post recession.  For hundreds of years, art and architecture usedt to be the symbolic representations of a city's prosperity.

Ok, If this is the issue for the Architecture meltdown in Enterprise IT, what is the solution?

Is the role of Architect dead and not required any more?. If not, what are the options in leveraging the best of Architecture and Architects in these uncertain times?

Have some suggestions...Stay tuned for my next post.