Since I started my IT career in the early 90’s, up to the mid-2000’s, there is one thing that all my mentors, somehow, always asked for me: “A consistent and well-structured drawing of the solution”, no matter if they wanted to see it first as a sketch, on a board or in a piece of paper; or if they just wanted to see it directly in a presentation tool. This, was only related to the fact that the some were less focused on the beauty (for the sales) and more comprehensive to my daltonism than others, but the important is that I learned from them that informational solutions requires a drawing, and therefore it gradually became a habit, and it is as is has always been in my blood.

The reason is quite simple, data need to flow to become information. If you are proposing it to flows from one place to another, you got to draw the “from-to” and the “how-to”.

So far, no news for anyone minimally involved with IT projects, and for IT people things have been like this since God’s “Let there be light!”. But, as the years passed more and more systems were necessary, as well as integration and interfaces between them, sometimes increasing gradually, sometimes boosting the amount of generated data.

Happens that the data warehouses showed up, and with it, so the “popes”: Bill Inmon, Ralph Kimball and Dan Linstedt (https://blog.westmonroepartners.com/data-warehouse-architecture-inmon-cif-kimball-dimensional-or-linstedt-data-vault/)  three different approaches, but all of them highly drawing intensive; just google it, select images and you will see a myriad of schemes to depict this 3-in-1 below:

By that time, I was a SAP employee and SAP BW Consultant. SAP BW was much more conceived with Inmon’s approach than Kimball’s, although it is not uncommon to find, even nowadays, implementations applying Kimball’s concepts. But the agnostic models were academic discussions and normally just 2 or 3 slides as part of the sales PowerPoint. Furthermore, the most usual IT behavior was select the technology/tool, and then come out with the information Architecture, at least in Brazil.

In 2010, I was no longer at SAP for a few years, but still in SAP market, when I’ve been hired by a company (A) – one of the biggest in the world on its segment – that was not a SAP ERP user, but was migrating to SAP. This company already had a few BI solutions in place and treated Information as a very important asset, so much that Information was an Executive Directory. And my duty was to bring SAP BW knowledge to the organization, but support a hybrid informational architecture and be the counterweight of the implementing consulting company and my ex-employer SAP.

The company had already a very consistent conceptual informational framework, and the BW implementation was taking place completely disconnected from it and thru the dangerous path of using, Kimball´s approach for any reporting requirement in SAP BW.

In my first logging in the system, I found the most chaotic SAP BW implementation ever, after 8 years in more than 15 different companies. Things were so bad, we decided set-up new and fresh landscape, meanwhile in partnership with SAP, to develop a conceptual framework for SAP BW based in the one the company already had.

By that time, SAP in the seek to solve the innumerous “problematic BW implementations” came out with one particular approach for BW implementations in big and worldwide operations companies, the Layered Scalable Architecture, or just BW-LSA. BW-LSA became the dream of architects and the nightmare of non-senior consultants and consulting companies. Basically, it aims Inmon’s CIF approach in very well-organized, structured and governed manner. But BW-LSA itself shall be discussed in one specific post in the near future.

Back to this post main argument, the job of adjusting SAP BW-LSA reference model to the company’s pre-existent conceptual informational framework has proved its value only in my next assignment. First, because I stayed many years in the company (A) as an Architect and always with the responsibility to produce alternatives not exclusively SAP driven. Second, because once conceived and in place the BW-LSA needed a “Sheriff”, awful position that fell in my lap also.

My next assignment, now for a company (B) – 5^th biggest in LA in its segment – was to provide an Analytics & Big Data Architecture. So, I thought that the challenge would be, acquire/update myself in the Big Data & Analytics technologies, but in the first meeting with the client, I’ve told that things were a little more complex, the informational architecture should be able to support the company´s next 10 years’ technology investment roadmap, that would leverage the company to operate in industry 4.0 mode.

Well, you cannot conceive an informational architecture that should be valid for the next 10 years based on technology A, or B, neither in technology provider X, Y, or Z. So, it was only then that I realized: the challenge would be greater than acquire/update myself in the Big Data & Analytics technologies, I would need to think agnostically to develop a design with no technology brands, no strings attached. Happens that now I was alone, just as in that old song “All by myself…”

What should be the main drivers of an agnostic/non-branded Informational Architecture? Well, since the post is already too long, I decided to break the article in two, so that for now, I will rank the drivers but the details will come in part II.

1. Non-disruptive/Minimal disruption
2. Multi-source enabled
3. Multi-granularity capable
4. No data persistency obligatory
5. Safe, simple and flexible governance
6. Allow different tool/solutions for one same layer
7. Enabled to use any end-user viz tool