City Planning and Government EA

I was just listening to a presentation about city planning and immediately thought about its likenesses to Enterprise Architecture.  Any group of people could collect in a location and begin building homes and roads and shops and eventually a city might develop, but the long term health and well-being of the city will be dependent on how well a master plan is executed.  Government organizations are formed when a group of people unitedly decide to apply common resources to establishing a framework for providing services for the common good.  That government organization will reign over the people, but the long term health and well-being of the government will depend on how well a master plan is executed.  That master plan might be called the Enterprise Architecture.   The phrase "health and well-being" is important.  There are many definitions in the world for what constitutes a healthy government and society.  My view is that a healthy government is one that enables people to live and develop in a safe society--the government should, like a good family, encourage people to overcome challenges on their own, help one another succeed in their good endeavors and help them become independent, contributing members of society.  I have noted, in a previous post on this blog, that a government organization, unlike a private sector organization, doesn't strictly depend on out-competing competitors for resources.  The government organization (or rather, the resources applied toward an organization's functions) will grow and survive dependent on how deeply entrenched it gets into daily operations of the government and society.  However, it can, like a cancerous mass, grow and survive indefinitely to the detriment of a society or to its benefit and long term health and well-being.  When the government mandates an Enterprise Architecture approach to its maintenance and growth, it must be recognized that its (the organization's) survival depends only on its leadership's ability to convince the right resource providers why they need the resources.  This is in contrast to a city plan, a city will grow and survive based on how well it supports an environment in which people will choose to settle and do business.

SOA and Event-Driven Architecture (EDA)

I was just thinking about these concepts and how they relate to public sector organizations like the US DoD.  It seems to me that private sector organizations bring themselves into existence, there is a struggle for "life" with multiple competitors, a constant struggle for resources constrained by natural laws,but freely available,  therefore a constant "evolutionary pressure".  In this type of environment organizations must be concerned with how best to utilize their own parts and pieces to maximize or optimize their growth rate.  Therefore, rapid, effective response to changes in the business environment in which they operate is highly desirable.  Among the benefits of SOA and EDA are organizational flexibility and agility in the context of the competitive business environment.  In the US DoD, the environment is quite different.  First, the organization did not bring itself into existence nor does it remain in existence simply by its own efforts or struggle for "life".  The concept of competitor is irrelevant because a competitor, by definition, threatens to end another's existence by taking more of the common resources that each competitor requires in order to remain in existence.  Furthermore, resources are not constrained by natural laws, nor freely available, so that resources are not truly the mediating factor influencing the existence of public sector organizations. What does all this mean with respect to SOA and EDA efforts in the US DoD?  I believe it means that the success or failure of these projects is much more subjective and difficult to judge.  These types of organizations must carefully choose judgement criteria based on their operating environment.     

The Golden Ratio and other Mathematical Concepts and Information Management

The Golden Ratio, also known by many other names, has been applied in designing works of art and architecture for centuries.  One result is the aesthetically pleasing quality imparted to a design.  However, I believe there is also a functional element that makes it a practical design technique as well.  My question is whether there are ways to apply this ratio and/or other mathematical concepts to information management.  The complicated distribution and relationships of information in a given individual's life reminds me of some of the complicated puzzles that utilize mathematical concepts in design and solution.  Is there some way to analyze information and organize it by using mathematical concepts?  I am thinking specifically about program management information.  I have been working in the government domain for 8 years and have yet to see anyone who can effectively track all the information related to a program.  The amount and dispersed nature of information are two factors that make this so difficult.  Can this be related to a "Rubik's Cube" type of puzzle?  A multi-faceted, multi-attribute, aggregation of information that has to be kept in constant alignment. 

Service-Oriented Architecture

I was thinking about this on my way to work this morning.  In trying to understand SOA in terms of more everyday elements, I considered my truck as a piece of "hardware" in my enterprise and the CD I was listening to as an "information" requirement I have identified for my enterprise.  That information can exist in a "database" (the CD) that is necessarily upon my car's hardware component (the CD player).  If the CD player is not designed to play MP3 file formats, I may not be able to access some "information".  Additionally, the CD player requires some maintenance and I have to expend a certain amount of resources (time, physical energy, money) in acquiring the information (CDs) that will be of greatest worth in my enterprise.  Now, I started thinking about applying this example to SOA.  An enterprise requirement is that I be able to access information and decouple the source of the information from hardware solutions.  Essentially, I want certain information delivered to my truck without another intermediary piece of hardware.  How about having satellite radio to which I could subscribe and through which service I could directly acquire any and all relevant information?  In this scenario I see that I have cut out the intermediary hardware component (CD Player), but I still have an essential couple of components--the satellite radio and antenna.  What has changed is the information delivery interface to the enterprise, the existing enterprise component must be changed out, and a new datalink must be described.  My business process for acquiring information must also necessarily change raising questions about personal information security.  Namely, how will payment for the service be exchanged?  Will it go over the satellite data link or through a strictly ground-based network.  Therefore SOA is not about simply describing Services without regard to Systems.  It is about accurately describing the information delivery interface, required communication links, and business processes.  

Enterprise Architecture: Why it won't make a difference . . .

I've been hearing the complaints from our accounting and payroll person about a new financial management software application we've just deployed.  It doesn't meet her needs, it isn't user-friendly, it doesn't have the interfaces to other software tools she currently uses to do her job.  At first I thought all of this could have been avoided if only we had a functional enterprise architecture.  Today I was reminded of a cold reality.  No matter how well we might have understood our enterprise, in the end the budget decided the solution.  We needed a packaged solution and we simply had to take the good with the bad.  I suppose that if we had a good, functional enterprise architecture we might have been able to manage expectations a little better, but it wouldn't have made a difference in the solution architecture to which we are forced to adapt.

Information Management Research Results

• Improving information management
• |
• silicon.com videos

Don't Rush to Technology

I believe that too many organizations rush to technological solutions to their problems.  The technology can help, but depending on the problem, it will not be a complete solution to the original problem.  It is important for the organization to understand the problem clearly and completely.  For example, I believe that an enterprise architecture is an important undertaking for most organizations and there are many technological tools that facilitate the capture, storage, retrieval, and correlation of enterprise architecture information.  The question is: what exactly is the problem that the organization wishes to solve by developing its enterprise architecture?  When the problem is well-understood, the best decision will be made.  It might be appropriate for an organization to first make behavioral changes without technology and let the new behaviors become well established before introducing new technology.