Wednesday, July 1, 2009

Need a Reference

Yesterday my colleagues and I were talking about Enterprise Architecture (EA) isn't just about classifying metadata but rather it is more than that. I agree that statemen. By classifying systems, processes, data, applications, resources, technologies and other aspects of your Enterprises, we begin to understand our enterprise but it also builds defines a reference point from where we can understand the architecture.

Defining the reference point is key but how do we define it? Usually having some requirements that the architecture is trying to address or solve is a great place in defining your reference point. If we are trying to optimize the inputs and outputs of a system then the architecture is going to focus on the inputs and outputs of a system rather than the internals of the systems or the external clients of the system. After defining where the reference point is, we need to define the reference point. This is not a easy task since the point could a be a subsection of a system (compononet), type of of subsystem (aspect) or a combination of (collection of components or aspects). A good starting point is have your original requirements and now you look at various architecture frameworks to see if these frameworks meet some if not all of requirements. You can also create your framework by stitching together a collague of frameworks. The secret ingredient in selecting your framework is to understand if they really meet the requirements and you, as an architect, can defend your architecture.

These principles are true when you are designing a complex ontology, a metamodel or even a process. In data architecture, we can literally derive infinite relationships between data entities and attributes but in the end does your data architecture meet the requirements and address the problems. Data relationships can jusitified in a relational database model, metamodel or a class model however all these models should compliment each other and should not contradict each other. To understand if these models are truly complimenting each other and not contradicting each other, you need to have a reference point. The reference point should address the following:
  • Does the Architecture address the requirements?
  • Does the Architecture capture granularity at the correct depth?
  • Does the Architecture validate in various use cases and scenerios?
Hope this blog blurb helps you to be a better architect.

Sunday, June 28, 2009

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.

Saturday, June 27, 2009

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!

Thursday, June 25, 2009

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.

Wednesday, June 17, 2009

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.

Sunday, June 7, 2009

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.

Friday, June 5, 2009

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. :)