Technical Architecture and the silos thereof....
I was recently sitting in a café a flipping through a magazine on Green Architecture for Retailers. It included the entire gamut of retailers - apparel vendors through grocery vendors and how they wanted their stores to be green; Emphasis on green paints, green lights, recyclable paper towels and so on; the investments and the returns thereof; testimonials that justified the idea, the ones that stressed on the longevity of these implementations and those that cautioned the reader.
I constantly kept imagining the role of the architect that evaluated a retailer space and proposed the ideas that could be effective. The ideas that would make the environment more smart, more reactive and therefore more effective and worthwhile.
I have too predicted and emphasized such smart and agile options here and here for Supplychain implementations. But in this article I want to stress on the silos we the (Technical) Architects face. With the landscape architects we have the entire store being assessed and evaluated for improvements. Then they go back to their drawing boards and create a plan that works best. Upon winning the proposal they have a host of teams to support their ideas – carpenters, plumbers, upholsterers, construction workers, electricians and so forth.
So why am I so worried about a field that doesn’t concern IT? Well, I do have a point.
Today with the ‘advent’ as I like to call it, of the technologies like virtualization, grid, cloud etc, there needs to be a bit of direction to the way we use it. It involves the client who is paying for it, the service providers executing the NFR and recommending the changes, and host of team to back that up.
I have been with multiple clients across the globe and I don’t think any of them are exploiting these technologies to the maximum. Some places the resources are appropriated on an application by application basis like in the 18th century. One may argue this is fine as long as there is a roadmap for server consolidation. But that is not the case.
At other locations I find huge farms for each tier – hundreds of 64 bit p6 servers for databases for all the applications in the enterprises’ landscape being underutilized. But then the question is if we can expand these farms anytime why procure it so early.
In my opinion it is because of isolated IT roadmaps. DBAs are consolidating the database servers while the AIX team has their own version of adopting and adapting to virtualization. Storage team doesn’t know about the DBAs or the AIX team and they have their own version of SAN improvements. Lastly it is the pitiful you working as a technical architect trying to establish an architecture for the OMS application at the heart of the enterprise’s application landscape. Any technical architecture deliverable without proper assessment of the infrastructure etiquettes at the client site will therefore be irrelevant at best. (For example, you may write section on HA and DR for the application that will be deployed on a farm that already has HA-DR plan. You may suggest RAID 10 while the standard at the client site is to use RAID 5).
So how do we get around these silos of teams? Well, you can’t. Now, that won’t work will it?
I think although this has to be dealt-with on a case-by-case basis, I can’t stress enough how important it is for a technical architect to spend a couple of weeks to understand the dynamics at the client site before dwelling deep into gathering the application specific NFR. Once the landscape is evaluated, the silos wont be silos anymore and it becomes easy to propose a technical architecture for an OMS implementation. The architects will be talking in terms that the DBA's, Unix Admins, SAN teams, EAI teams can all understand and relate to.
I will perhaps write another blog describing the PRE-NFR steps. Stay tuned.