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.