Are You Worried - Is the Technology or Architecture Reason Behind New Systems Fast Becoming Legacy?

Often when we hear " Technology" is changing, actually the person in the context is actually trying to say that "implementation" is changing.

John Zachman says that a quick way to qualify something as "architecture" is to check if there are definitions & specifications are complete & consistent, are they sufficient to create an instance of implementation, whether it can be used as a reference (basis) for making changes in the future.

In the context of architecture (reification), the word "specifications" is more appropriate for the word "technology". And you will quickly realize that "specifications" are less likely to change than the implementation. In fact, "specifications" in turn are derived from logical systems of data, function, network, User Interface (access & roles), timing (events) and rules. That means rate of change in "implementation" is faster than "specifications". And the rate of change in "specifications" more rapid than "logical systems". So, if we could separate the implementation from specifications, and separate specification from logical representations, we can possibly address the issue at hand.

Now, this is difficult to comprehend by those who think Architecture is details of implementation. For them architecture is inside the “implementation”, so as and when technology implementation changes, they are in panic mode. There is immediate need to improve the quality of discourse by separating the idea of "architecture" with "instance" of implementation. That means one architecture can have multiple technology implementations. That also means, a good architecture will support ever changing technology implementation.

Are we often confusing idea of IT Architecture with details of IT implementation (programming)? Is this problem more rampant in India?

  1. Today, India has large development centers of global End User companies as well as IT product companies which are leveraging low cost talent pool. In most cases, IT Architecture decision are taken at HQ.

  2. In order to glorify and motivate programming teams, are we misleading them to believe that detail of implementation is the architecture?

  3. Since, most development teams are judged based on performance indicators like lines of code etc…so more maintenance would mean more revenue?

  4. Development teams are using new buzzwords that promises results by ignoring key steps in architecture

  5. Programming process is oriented to meet the expectations of the day. And all the methodologies, materials, tools are aligned with that

  6. Isn't it true that all systems are legacy before they are even deployed?

If the speed is everything, and if systems are legacy even before they are deployed, what's the solution?

At ICMG, we think that the solution is in ability to CHANGE. Ability to quickly change what you have developed, that's the key. In fact, ability to change what you have already changed is the key. And unprecedented ability to change, agility to adapt can be achieved with the help of Architecture. Is it agility to deliver or is it agility to change? Or Both? Is it agility to deliver first version or is it also about agility to deliver second, third and fourth version?

Ironically, if you have architecture in place, you can be agile with your first, second and third version. In addition, it costs less. But, some people think otherwise.

Do you know why do we do architecture in other matured industries? Because, they have less budget, less time and systems are complex. So if you thought or over-heard, doing IT Architecture means delay, more expense etc....something is wrong there. Isn't it?

0 views0 comments