Build Vs Buy and more...

I honestly believe that the way Information Technology is done is becoming archaic. For example the typical Software Development Lifecycle (SDLC) is still geared towards to client-server based technologies. Can we say Visual Basic 6, FoxPro, Sybase with back-end relational databases in Oracle, SQL Server, Access? Unfortunately working in the Enterprise space, I have realized that businesses don't want to build every application they desire. There are Custom Off The Self (COTS) software which can be configured to a point where it can used out-of-the-box. The big question in the Enterprise is Build verse Buy. This means do we build the application or buy the application and then use it with mininal configuration. Enterprise Architecture expands the Build Vs Buy problem to Build Vs Buy Vs Reuse functionality from existing applications. In theory this sounds great however there are drawbacks going the enterprise route. There is greater dependency on the enterprise for reuse functionality from existing applications. However if the enterprise is not mature enough then we have to go the "Silo'ed" route since silos impede information flows and exchange but they also protect the systems and programs from risks in an immature enterprise.

In the end, enterprise level IT is good however it is bad if the enterprise level IT is extremly immature. Do we trust our neighbors or do we trust ourselves?

Wave needs work

I finally got my account on Google Wave "Preview" version a few weeks ago. I invited bunch of techie geeks like myself and now we wave. Right?! Wrong!!!! People just don't know how to use it. Wave's email doesn't work. So if you want to email me at enoch.moses[at]googlewave.com then it will get bounced back. There attachments functionality does work yet . I tried sending a descent sized PowerPoint slide deck and I believe it is still loading. Wave folder functionality doesn't work. I guess most of the stuff doesn't work because it's a "Preview" version. I would rank Google's "Preview" version as Oracle's "Production" version. Stuff is supposed to work but it simply doesn't.

I do like the concept and I tried to wave but no one waves back because you really cannot wave. Not even blip well. So get an account and be patient.

Goodluck!

Waving looks good

A week ago, I got a developer account to Google Wave and I am informally testing the application with the accounts they have provided me. It looks good. The concept is simple and a powerful one. A wave is composed of wavelets and wavelets are composed of blips. A simple chat entry, a sixteen page blog entry or an email entry can called a blip. A collection of blips can be captured as a wavelet and a collection of wavelets can be called a wave.

So how is it powerful? It's a great way of organizing information since all of the relevant information for the relevant context are tied together. Currently it is hard to follow emails. For example I get emails from Sender A, who wants to know what I would like for take out, are interspersed with emails from my boss who wants to know the status of my IT projects. The tone and formality of the two email threads are different and it would take me more time to adjust to the "lingo" of the different emails. Recently I am slowly switching my email from Yahoo to Gmail because I like the way Gmail organizes their information.

What I am really excited about Google Wave is for enterprises to mine the data. Imagine tagging the wave and sub taggine the wavelets. Wow! The possiblities are endless! Can we use this model in organizing our Enterprise information?

One thing I don't like about the way it is set up right now is that their emails and waves cannot be viewed in the view. It makes the UI confusing and may confuse some users.

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 statemenr. By classifying systems, processes, data, applications, resources, technologies and other aspects of your Enterprises, we begin to understand our enterprise but it also 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. 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 must 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.

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.