Often when we hear "Technology" is changing, actually the person in the context is actually trying to say that "implementation" of "technology" (specifications) 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.  

 

Now, this is difficult to comprehend if someone thinks 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 an 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.

 

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, UI (roles), timing (events) and rules.

 

That means the 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. 

 

Why You Should Sign Up For This Discussion 

 

• Are we often confusing the idea of IT Architecture with details of IT implementation (programming)

• Is this problem more rampant in India?

• Today, India has large development centres 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. 

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

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

• Development teams are using new buzzwords that promise results by ignoring key steps in architecture

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

• 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? 

• Is it very expensive to gain agility to change? Is it time-consuming? 

 

At ICMG, we think that the solution is in the 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 the first version or is it also about agility to deliver second, third and fourth version?

 

Ironically, if you have the 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? 

 

Please join and discuss your experience with our panellists.