Essence of IT

Last week I got into a discussion where folks were defending a SDLC process and stating that the process is great however the practitioners were not good in implementing the process. Hold On! Practitioners are not good in implementing a process? Can we ask a junior programmer to implement best practices like design patterns and ask him or her to code to the Model View Controller (MVC) paradigm? I, personally, expect a junior programmer to create a class (sorry using Java lingo since I work with Java) and to implement a driver method in "public static void main (String[] args){}" where the programmer will write multiple lines of code starting with System.out.println.

My big problem with the statement, "the process is fine but the practitioners are not", is that in the short term it is easier to change a process than to change human resources. If you state that the process is fine but the practitioners aren't then it is time for you to move to the white ivory tower in the IT Neverland and think why isn't anyone coming to the tower. The process maybe fine however if no one is using it then it is time to alter the process, get people to use the process and slowly but surely move the process to its original state. If people think that the SDLC is too complicated then simplify it and get project managers (PMP certifcated or not) to start using it. Get them excited and let them suggest changes in improving it. This way they think they are the agents of change but it infact they are maturing and appreciating a well defined process. This is of course that the practitioners do know something about their domain. If you gave me a copy of Microsoft Project when I was a freshman in college and ask me to manage a $250,000 project with 3 developer then I would now say no process would have helped me since I was clueless. If a person is in a leadership role in a IT department then he should know something about the IT domain like system development. I am not going to ask my wife to lead a system development project since she has never been associated with IT systems other than using the internet.

In conclusion, the essence of IT is the people who work in the IT department. Lets respect them and give them some credit. If they cannot do their job then it is time to train them and give them a second opportunity. If they still cannot do their job after training then it is time for them to get out of IT. I hear Obama is asking for volunteers to work in the community.

Can't Base Everything On...

I have been following Gartner and Forrester's research content on SOA, EA and other IT concepts from 2005 till present and I have learnt the following:

• Do not base ALL your IT decisions on Gartner and Forrester's predictions and recommendations. I have seen large IT companies make investments in technologies and products where the investments have not panned out because their IT environments are quite different. For instance SOA was the hype in 2005 however current Gartner analysts are saying that SOA simply doesn't work well in most IT environments. Research analysts tend to do that alot since they are reacting and analyzing current trends and make predictions and later contradict their predictions.
  
• Scope Best Practices and Products using Research. Rather than testing ten separate products for your certain IT requirements, you can choose the top five products as assessed by Research companies like Gartner and Forrester. Do assessments on the top five products and see how well they meet your IT requirements and how well do they perform in your IT environment.
• Use Research for Initial Business Justification. If you are looking to address a business problem and you want to follow Gartner or Forrester's recommendations then use their material to carefully craft a business justification on why you want to prototype their recommendation. Please keep in mind that you should address Return on Investment even if the recommendations don't work for IT enviroment.
• Engage these Research Companies. You want to market your IT strategy and progress then I highly recommend that you keep a lively engagement with the Research analysts where they will refine their research using your enviroment's results and at the same time they will give insight into current best practices. But be careful not to waste their time or yours by not having a detailed strategy on how you want to execute your vision and how you want to collaborate and market with these Research companies.
• MOST IMPORTANT: Consider the Research material however stick to your vision and requirements in executing your vision. Afterall you know the 50K feet view and the 1 inche view and therefore it is your responsiblity to execute it.

Good luck!

Actionable Enterprise Architecture

We, at work, are trying to define what is Actionable or Usable Enterprise Architecture (EA). As many of you that EA is a capability that almost every Chief Information Officer (CIO) has in his Information Technology (IT) Department. The exact definition of what EA means is different for every IT shop. Now trying to create an EA which delivers business value to an IT Department and to the overall business is as elusive as finding Weapons of Mass Destruction (WMD) in Iraq. Actionable EA is not easy. Folks at US Government agencies think EA is a capability to add OMB Exhibit requirements. This makes things a bit harder. Anyway here are some tips to make EA successful in your IT department:

1. What is the organization trying to achieve by having a EA capability? Each organization has different expectations for EA capability.
   
2. Know your stakeholders and understand EA requirements: Identify the stakeholders in your organization who will benefit from the EA capability and then get to know them and understand their EA requirements. This way you are also marketing your program and capabilities.
3. Have a Starting Point: Most EA folks say having a good EA framework like TOGAF or DODAF is a must since it helps you identify the various components of your IT Department and then you can use the framework as a gauge to see how IT Department is maturing and progress. If you don't have a framework or don't want to use one then identify various components in the IT Department, model them, access maturity and bimportance of each component within the IT Department
4. Take It Easy - Don't propose strategies where whole IT Department is documented with extra fine granularity and various tiers (data, infrastructure, application, business, etc., etc.) of the enterprise are concurrently trying to improve their tier. Atleast initially, you should address a set of systems, see how your strategies are being implemented and then refine them for the next iteration.
5. Market, Market and Market some more - Tactical functions within an IT Department like Help Desk support, Data Center services won't understand the long term benefits of EA. It is therefore beneficial to publish a EA website or a knowledge management site like Wiki. This allows people to understand what EA means to their IT department and we can level set their expectations.
6. Problem Solving: - Show me an IT Department without problems and I will show how Pigs can fly! Every IT Department has problems related to policy, process, systems, resources, etc., etc. It is our job to show them how EA can solve their problems.
   

President 2.0

I believe our President has done it. President Obama is using technology to its fullest to , do his job. He is pushing his agenda through his websites, grass roots campaigns, twittering pages, YouTube videos and many others. In fact I writing a blog about his use of technology, is an accomplishment. Currently he is pushing Health care agenda and I, personally, am skeptical about it but I admire about him is that he is pushing critical issues to the masses using web technologies. True, a regular Joe won't be able to vote a "Nay" or a "Yeah" in the Senate or the House but at least I am aware of the issue and I can start a grass roots campaign for it or against it. I can also use technology to push my voice using Blogs, social networks and other Web 2.0 enable medium. I have admired how Obama has used the Web to rally the people to campaign for him. I signed up on his site when he was running because I was curious and I wanted to see what he is all about. I read up on the issues on his site and McCain's which helped me make a decision on my vote. I also got an opportunity, which I took, to volunteer at the Presidential Inauguration. It was a great experience and I wouldn't have been able to experience it if Obama wasn't reaching out to the masses via the web. Anyway he is revolutionizing on how campaigns are done because his usage of technology. I wonder when President 3.0 will come. Stay Tuned.

Here is a video of Obama's healthcare from PBS which includes my friend Jonathan's wife Zaneb Beams. Even if you hate Obama, you have to appreciate how he used Web 2.0 technologies.

Twitter-mania!

As everything has a "buzz" lifespan, Twitter seems to be growing and various entities like my former employer, ManTech International and others, have started Twittering. I have been twittering for a few months and I have seen that it is a great way of creating organic social groups or Communities of Interest (CoI). For example I tweeted about "Groovy on Grails" and next thing I know, I am being followed by Grails evangelists. I have had web designers requesting me to let them follow me since I tweeted about Photoshop and other Adobe products. It is a neat thing that people are following micro-blogs since people don't have time to read large blog articles. I have discovered that with Twitter that you can create a buzz about yourself or about some of the actions you do. I have seen people Twitter about their skills to market themselves. I have seen entities like CNN Breaking News which tweets the latest stories in news. I follow Pete Carroll who markets USC and how cool it is be a USC Trojan. I also follow Shaq and Mark Sanchez, Jets QB draftee from USC and many more. The question is why I do enjoy following them and other one million plus who follow Ashton Kusher. The answer is that it gives a person insight into celebrities. A way for us to relate to them. They are human like us. For example, Mark Sanchez loves hamburgers and he is always tweeting about Hamburger joints in NYC or his practices at the NY Jets facility. I, personally, like following people I know since it gives me a better insight into their lives.

Now I ask the question, "Does it make sense to have companies like ManTech International Twittering?" I answer that asking another question, "What are they trying to achieve?" Is it recruiting tool, employee retention tool, or a way to generating more buzz? I suggest that they should first monitor who is following them? Is it ex-employees like me or is it current employees or someone totally different? As an ex-employee, I would be interested if they had any interesting positions open up. If I were a current employee then I would like to hear about new benefits or about some new business and potential career development. If I were an outsider, I could be a competing business, a potential stock buyer, a prospective employee or a prospective client. The question is what are companies trying to twitter? There is a market there but some creative analysis and speculation may increase a company's image, moral and the quality of the work force. As for me, I wish Twitter had a better UI.

Consultant - The Human Tool

As a US Government employee, I am constantly bombarded by contractors wanting to provide their services and vendors who are constantly selling me their Custom-Of-The-Self (COTS) products. Therefore as a US Government employee, it is my duty to determine if I need consultants and COTS products for some of my organization's strategic activities. As a goverment employee, my primary responsibility is to accomplish my organization's strategic and/or tactical objectives while managing to be diligent stewards of US Tax dollars. Anyway here are some thoughts regarding consultants:

• Don't let the consultants drive the strategy for your projects - The consultants try to couple themselves to your organization processes and try to you dependent on their services.
• Be up front - Tell the consultants what your expectations are of him and how his performance will be monitored and assessed.
• Monitor their perfomance - Hold them accountantable to the project schedule and demand deliverables to be met on time.
• Take ownership of the Spend Plan - Don't let the consultants manage the spend plan for you. This is a big no, no. Take ownership and decide how you want to mange it.
  
• Define and demand deliverables - Define the deliverables and when they should be delivered to you. Keep them accountable for the deliverables.
  
• Consultant Scope Creep - I call this when consultants are working with you to know your domain and they might try to expand the scope the deliverables and push the date back. This is not a good idea.
• Believe in a Reward system where consultants can be retained because their project were successful or show them how they can retained with their good work.

In the end, consultants are nothing more they glorified Enterprise Architecture Tools. The consultants will do what they are told to do within the context of the agency. Having good requirements on sort of consultants should be done by interviewers and sharp managers would thinking about their potential reuse after this project. The only problem with the consultants is they don't have a new version available. :)

IT Role Players

Today I had a conversation with someone about the difference between an analyst and an architect. This blog entry comes out of this discussion where I share my opinion about various Information Technology (IT) roles.

• Analyst - Someone who spends time analyzing, decomposing the subject matter and sometimes provides the best option depending on the requirements. This person is not involved in coming up with a noveau solution but rather is involved in doing detailed analysis. There are requirements analysts, business analysts, process analysts, chain-management analysts, financial analysts, technical analysts, security analysts, program analysts, etc. etc.
• Architect - This role is a confusing one. I have heard that it is every developer's goal to be an architect or this person is nothing more than a technically savvy project manager. I have also heard that an architect is nothing more than a glorified analyst. After doing Architecture for eighteen months, I have to say it is a hard job. (Don't get me wrong. Analysts also have a hard job since they have to extract their analysis from information which is explicit and implicit). Architects take the analysis from the analysts and synthesize a solution for the problem. The architects have to consider the tactical constraints and its alignment with strategic goals. This person has to constantly ask himself, "Does my proposed architecture satisfy the customer needs, align with the strategic roadmap, meet the project deadlines and can it be implementable with the current resources (i.e. resources, infrastructure, standards)." There are enterprise architects, application architects, software architects, solutions architects, infrastructure architects, services architects, data architects
  
• Standards Person - This person usually work in a Technical or Functional Group defining standards for a particular domain. He or she needs to have good analysis skills, architecture skills and most importantly have excellent written and oral communication skills. This person needs to level expectations with the organizations they represent in the Standards groups and at the same try to push their organizations requirements into the standards specifications. They have a hard job of strategically aligning the standards, (they are working on) and their working bodies goals and with the organization's goals. Word smithing skills should help. There are standards people are involved in technical standards, and process standards like Software Development Lifecycle (SDLC) and Configuration and Change Management processes.
• Engineer - This person is a problem solver and he is usually involved in the "weeds". Usually the architecture aligns strategically with the organization's goals, meets all high level requirements and meets all other constraints. However this person addresses the finer problems within the overall architecture and solutions that maybe temporary fixes or configuration changes. For example there exists a mission critical system which was architected perfectly however the user base has increased eighty five percent and currently the system is experiencing a significant lag time which is affecting a business process. The next release is in six months. This is where the Engineer steps in. He determines the problem, designs a solutions and implements it. He documents the problem, design and implementation for the architects in the next release. Voila! The engineer has saved the day again. There are software engineers, systems engineers, process engineers, test engineers, etc, etc.,
  
• Developer - This person takes the high level architecture, designs the low level design and then implements it. If the architecture doesn't address the details because the architect doesn't have the time to design low level specifications or if the architect is not familiar with the technology then he or she can leave it to the developer. There are usually software developers.
• Programmer - If the architecture is extremely detailed and granular then the programmer has to implement the design. This is done where systems are designed to interfaces.
• Administrator - This person usually administrates an IT function. A system administrator administrates the system by maintaining and optimizing it within the constraints defined by the architect and the engineers. There are system administrators, project administrators, program and organizaton adminstrators.
  
• Project Manager - This person is responsible for managing and delivering a project which has beginning and end states defined. This person has resources to manage and is responsible for the appropriate deliverables to be completed within the project timeline. This person is not strategic but his or her main objective is to meet the end state with the project constraints.
• Program Manager - This person is responsible for managing a program which inconsists of on-going projects, projects to be executed and projects that were completed. This person is strategic since he or she need to program goals however they meet their strategic goals via projects which are tactical in nature. These people are comfortable dealing with project managers and their projects.

Please let me know what you think. These are my thoughts and I haven't spent any time validating if my definitions meet PMBOK or PMI standards.