Buddy it ain't dream computing. It's reality!

A few days ago, I had an interesting conversation with my co-worker Bill about modeling to a specific project or program or should we model with the enterprise in mind.  I then asked the question.  Does it make sense to model data, business processes, or an software modules like the federate query for the enterprise?  The answer is No!  This is because the enterprise is an ambiguous area.  Nothing is clearly defined however every business and every person recognizes that there is a bigger universe than their specific project and program.  IT personnel will throw everything in the enterprise bucket if it is ambiguous, idealist or flat out dreamy. Architecting for the enterprise without requirements, constraints, road maps or even goals is what I call dream computing.  It is only possible in dreams.    If you want to argue with me or just disagree, I suggest that you hit the pillow and just dream about your reality.  Frankly in my reality, everything is driven by financial figures and what makes business sense.

So getting back to the discussion with Bill, if your organization wants to push enterprise level thinking, modeling, design and development capabilities at the enterprise level then your organization should have a strategy.  You can then validate the strategy by picking an architectural framework which meets the organization requirements.  The strategy should also be defined by the organization requirements.  The organization requirements can captured as quarterly goals and have an  idea how they want to achieve the goals.

After you pick the framework then you need to decompose the framework to understand how you can use it to meet your organization's requirements.  For example Department of Homeland Security  (DHS), Federal Aviation Administration (FAA), and other US government agencies use the Federal Enterprise Architecture Framework (FEAF).  The FEAF was developed by Office of Management and Budget(OMB) and it meets their requirements.  Unfortunately agencies like the DHS and FAA use FEAF to do data calls and develop roadmaps (40K foot view is an understatement).  This however leads to major heart burn among the agency's management community see FEAF doesn't meet any of their requirements.  The management community subscribes to Gartner and Forrester and these publications which state that EA is better than sliced bread (okay I am overusing the"sliced bread" phrase).  The management community then wonders why is our EA team so horrible.  They pester us with data calls and develop academic road maps using FEAF and they have no value to the agency.  This blog can go back about talking about the importance of communications from a EA program however I have blogged about this issue enough for the last couple of years now.  I am now going to talk about the individual agencies failing to develop a EA program with their ability to capture oranizational requirements.   If your government agency's EA program is done well then the data calls to OMB  should be a cinch. Usually EA programs complain about that they don't have any sponsorship.  In highly bureaucratic organization where you have to pick your battles, would you give sponsorship to an OMB centric program.  I don't think so.  This is also because the organization in general has not done its due diligence in defining their strategy.  The government agencies wait for answers from the top and are extremely reactionary.

Back to Bill's conversation.  I told him that you cannot  do anything in the Enterprise without requirements.  You can model the enterprise to n-level granularity or the n-level sub processes.  In the end it is a wasted exercise because businesses are not going to pay how many rodents get stuck in a plane. If management is forcing you to go the enterprise level then identify the framework and work with the approach I proposed.
Where is my pillow again?  I need to dream about new blog entry ideas.