There are a couple of different approaches to creating your architecture.
The traditional approach and most widely used is the bottom up. The bottom up approach followed an isolated domain scheme. You know the one, where the guy in the network group says we need to monitor our network without any concerns for other domains. So he created visio’s around the designs, a topology map for their domain, started doing pings and SNMP queries to make sure they were alive and functioning within capacity, etc. This worked fairly well as there were several limitations to what the network device could initially provide and what the management system could interpret or derive.
The most common problem with this approach came in the manner of change. Change comes in 2 forms, known and unknown. Even today, the known changes are sometimes not proliferated to all the required persons and managements systems. This leads to false outages on devices that are no longer in service or they are supporting something entirely different than what they were before. It also causes problems when the visio didn’t get updated and operations are working off outdated information. The other form of change, unknown, causes all kinds of havoc throughout operations and engineering. Nothing was updated (visio), no one know s the login or password to a device as it ‘just appeared’, it was put in to support some application so you don’t know how critical it is, etc. You get the point, basically chaos.
Ok, that’s just one domain. The other domains, systems, apps, desktops, etc all have their own struggles and don’t have time to really interact or share with the other domains due to priorities, resource constraints, funding, etc. They have a hard enough time taking care of their own backyard let alone trying to imagine all the other domains operating as one. No wonder the business sometimes considers IT a black hole!
The newer approach is more of idealistic, top down. The top down approach simplifies the complexity of multiple domains and acts as a facilitator amongst domains. Unlike the inverse approach previously mentioned, this approach starts at the application layer. It discovers which applications are critical to the business, and then automatically attaches the components and users that make up that service (below the app) while creating a relationship map. It is focused on what is important for the business just as much as IT.
Change is handled either ahead of time by staging the change or if the change is overlooked, this approach will re-sync itself to keep up to date with all changes. Yes, change is inevitable, however, this approach keeps up to date with all changes and almost removes the ‘need to know’ requirement (remember, in this context only).
Top down does come with its challenges as well. The biggest key success criterion is getting the buy in from the domains to want to cooperate with each other. In the context of this discussion, cooperation is defined as allowing discovery and sharing of data to happen in respective domains. I’ve been involved with discussions with organizations that do not want to share their information amongst domains unless they are forced into sharing ~ your project fails before it starts if this can’t be solved. Another challenge is consuming the information. You only need the pertinent information that you need to be successful with your goals for the Plan mentioned in my previous post. Having information that doesn’t pertain to your goals of your plan is like trying to eat an elephant in one bite or nibbling at the elephant. Real life example: Creating a database with loads of information doesn’t make it a CMDB. It might make a data warehouse, but in the context of what is referenced here, we need an operational management database (OMDB) which has the flavors of a CMDB.
Next up: More content for your architecture and answer ‘What the heck would a top down architecture document look like?'