The importance of having a Integrated Dashboard for better IT management

 

Having an Integrated Dashboard is helpful in terms of IT Management. At least it is very very useful in terms of standalone program management according to my experience.

What kind of support we can get from the Integrated Dashboard?

1) Have a glance of how many "Interfaces" or "Services" we have. There will be a search feature to search for the Interface or Service  that we want to go to.

2) To configure Interfaces' or Services' variables at run time. For e.g. SQL, SQL Input Parameters, Database Connection, FTP Connection, Email Connection and etc.

3) To deploy latest code to the specific interface or service. Any Source Repository tool such as Mercurial, SVN, Github, and build such as Maven and Jenkin will be integrated to this Dashboard. The dashboard will provide a button to build the latest source code.

4) To provide scheduler function to schedule the launch the specific interface or service.

5) To provide server health (CPU, Memory) monitoring options using existing API such as JavaMelody or others. 

All the above are some important features that an Integrated Dashboard can have. Of course we can add more things such as monitoring , audit and etc. And of course we have to try to make sure each and every of our "interfaces" or "services" will be registered under this Dashboard. To build this Dashboard from scratch is going to take tremendous effort.

My thought on future IT Work Process

Nowadays in a lot of organizations, we have the "Application Team", "Middleware or SOA or ESB Team", we have the "Infrastucture Team", "DBA Team" and so on.

Imagine a project needs to involve so many different teams just to implement a solution. I would not say this working model is bad or not efficient or whatever negative term you can think of. Because so many IT solutions were implemented this way. The thing is, however, usually when working with different teams, communication becomes very very important and we've got to deal with a lot of human factors due to this. Human factor is more difficult to deal with than any technical problem.

Many times a team needs to depend on another team to complete the necessary task first. Such dependency creates a lot of troubles when the dependent team works in silo and does not respond in time using different kind of excuses. For e.g. if the Development team wants to increase server memory or to request to open certain port or things like that, in this case the Development team has to approach the Server team and Network team, and this may end up requires the Development team to fill in dozens of form, to attend to dozens of meeting to provide justification and etc. From the business perspective, this is actually not "acceptable", you know, every minute counts in the business world.

So I'm thinking, why not we have "development unit" only, or we remain only the "application team", then we remove the Middleware team, DBA team, Server team and Network team. Each application team will have their own Middleware, DBA, Server Admin and Network Admin.  And we'll set up the "Architect Team" to govern the Middleware, DBA, Server and Network standards. The Architect Team will consist of Enterprise Architect, Application Architect, Middleware Architect, DBA Architect, Server Admin Architect and Network Architect to coordinate with each other. They are the one who set the standards to the whole organization and each projects, they have to provide the architectural details for each project and review the architecture constantly at different project phases.

Project operation wise, architects should be not involved at all. Project manager will have full power on his/her team member consisting of BAs, Developers, System Admins, Network Admins, DBAs and etc. In that case we can remove the "form filling bureaucracy" and improve the project speed.

I'm not sure if any organization out there is already doing this way.