DATA ARCHITECTURE STABILITY
Bill Inmon
Founder, Chairman, CEO, Best-Selling Author, University of Denver & Scalefree Advisory Board Member
DATA ARCHITECTURE STABILITY
By W H Inmon
The other day I was having a conversation with my fellow book author Joe Reis. Joe said that when he and Matt Housley were writing their book on data engineering that the subject of data architecture gave him pause because he said that data architecture was a “squishy”, ever changing subject.
There is no question that data architecture indeed changes frequently and for lots of reasons. But it got me to thinking – is data architecture really “squishy”? Can’t we really pin things down once and forever or does architecture eternally change as the world changes? I really hate the answer I am about to give you but it is the truth – data architecture is both squishy and rock solid at the same time.
Now how can that be? Isn’t that a contradiction in terms?
Let me explain.
Consider the following simple diagram.
In the diagram we see the globe of the earth, the state of Texas and a street map of Dallas Texas. There is a relationship between the globe and the state and the state of Texas and the city of Dallas. So there is definitely a relationship between the different geographical entities. In the same vein, from a data architecture standpoint, there is a relationship between the major entities of the corporation, the data bases that represent those entities, and the applications that use those data bases.
The same sort of relationship exists between the geographical elements as exists among the architectural elements. And the degrees of stability vary as well.
The further up the chain of stability you go, the more stable the elements become. The further down the chain of stability you go, the less stable are the elements, for both geography and data architecture.
领英推荐
For example, the continents of the world are very slow to change. But new streets are being added and altered on a regular basis. And the major entities of the corporation don’t change very often. But applications change with regularity. Parts of the data architecture change regularly and parts remain very stable.
So as the chain of stability for elements descends, so descends the stability of the discipline.
This means that at a high level there is great stability of data architecture. To that end, the stable portion of data architecture has been captured in an architectural rendition/paradigm. You can get a free copy of the structure of the high level of data architecture by going to the web site – forestrimtech.com and looking for data architecture. When you tell Forest Rim who and where to send it to, you will receive a generic description – an architectural rendering - of what data architecture at a high level needs to look like. For free.
Of course once you acquire the rendering of the high level data architecture, you will need to customize the architecture to suit your needs and purposes. Customization of a high level architecture is always a requirement.
But getting the high level architecture right is the first key step in getting building a corporate architecture. Getting the path right from the beginning sets you off down the right path. And now it is easy and free to get off to a good start.
Doesn’t get better than that.
To get your free high level architectural rendition, just go to
???Forestrimtech.com
??And look for data architecture
Tell us where to send it to and it will arrive shortly.
Bill Inmon lives in Denver, Colorado with his wife and his two Scotty dogs - Jeb and Lena. There is a lot of snow in the back yard. Jeb and Lena have worn paths through the snow. So occasionally you look in the back yard and see this little tuft of black hair waving in the snow. ?Scotties have short legs so when they get in a trough there is not much to see. Just some little black hair scurrying about. You know that Jeb or Lena is in one of their troughs.
Data Engineer and Architect | Best selling author and course creator | Recovering Data Scientist ? | Global Keynote Speaker | Professor | Podcaster & Writer | Advisor & Investor
2 年Good article, and totally agree. For me at least, architecture's squishiness comes from almost infinite definitions of architecture. It seemed like for as many architects I'd interview, I got just as many definitions. Most of the time, architects would give me a blank stare and spout word salad when they realized they couldn't articulate what architecture meant to them. Various architectural frameworks were also all over the place (we cover those in the book). Many of them seemed too rigid. So, I had to peel back the immutable parts of architecture, balanced against the rapid pace of change both in and outside the enterprise, and provide something that served the purpose of the book, which is targeted at data engineers. Here's how we defined architecture in the book "Enterprise architecture is the design of systems to support?change in the enterprise, achieved by?flexible and reversible decisions?reached through careful?evaluation of trade-offs." I can't say I'm totally happy with this definition , or this chapter in general (I'm sure some people will like it, others will hate it). But it reflects the reality that you need to aim for stability (as you say), balanced against the need to be flexible in a rapidly evolving world.
Systems/IT Operations Manager at MAFM, BSA/Product(s) Owner
2 年I would suggest that things need to move in a direction that points 20+ years into the future. And that we start moving in that direction today, not as a reactive response but realizing, not just thinking about the things that will be in existence 20 years from now. Squishy is a mindset, not a reality.
Analytics Leader | Data driven decision making Evangelist | Business problem solver | Unlocking value from data | Mentor | Business Transformation |
2 年That is an interesting analogy, Bill. This works because there are certain rules at play. A state, and further down county etc., can create new streets/lanes etc. but they have to follow the protocols (zip codes etc.) And each state is responsible for rolling up the data which then allows the country (and further up continents) to stay intact. State, Country and International laws maintain the sanctity here. In typical organizations such rules are rarely at play though, creating madness. More the reason for Data capture, Data rules and Data Architecture to be central to an organization and not an after thought. Great post, as always.
From the pillar, the cornerstone, the torchbearer, of sustainer, the stalwart, the bulwark, the bastion, the tower of strength, the champion, the Chairman of the Board, and the Chief Stability Officer, Bill Inmon writes about and rights DATA ARCHITECTURE STABILITY. #dataarchitecture #billinmon
Real Estate Data and Analytics at Fairstead
2 年Love this... since the high level architecture is more stable and permanent, my assumption has been that you could draw a line where modularity starts. Why couldn't the different systems share the same template architecture until neccesary to diverge? Perhaps my greeness is showing, but I like how clean a stable high-level foundation sounds.