Fundamentals of Architecture

Updated: 6 days ago

As part of our research we go through a lot of our customer meetings and review questions asked and the content of that discussion. Rapid development of technologies across Big Data and the evolution of RDBMS into highly available in memory systems has changed the landscape of what we are used to dealing with. While a lot of the discussion is still about Cloud, we noticed some interesting parallels in some of the discussions. A lot of what we are seeing is multiple architectures that are being proposed across different business units to achieve objectives. There is an age-old debate about Platforms vs Architecture that we are not going to get into but fundamentally different architectures across the DevOps landscape can literally halt the synergy required to really be able to execute. What should you be looking for when you are asked suddenly to go to real time and authenticate many IoT nodes? Should it be based on what you have done previously? Or do you enter new ground and bring in new technology.





To start let us look at how you should look at platforms. At the very core these are systems with components of low variety common to the platform. Low variety is considered core to the platform and alongside that are complementary peripherals of high variety. These give the platform its uniqueness but also is where you should look at fundamentals of unity. The reason for this is the fundamentals of unity are required to propagate these platforms into a larger architecture. While we understand it is scandalous to talk about platforms forming architectures, I would propose that this is more of a reality than a constraint. While it is nice to postulate in Enterprise Architectures it is often like data management where the need to get the data into the system overshadows the requirement to manage, cleanse and set governing standards for the data. If we are growing through platform development, then there needs to be a fundamental unity to the platform and historically you can see business trends have taken a lot of this into account. SAP got into it by buying Business Objects and all of their solutions which by the way were not on a common platform or of low variety. Hyperion was I think one of the first to drop being purchased by Oracle. The problems became manifest because as Hyperion upgraded to a more stable version it also had to deal with an overlay to manage it through Oracle components. Analytic platforms continue to be purchased so that the idea of the platform enables customers to stay with one vendor but based on our definition we really need to look further to see if fundamental components are of a low variety.


Problems occur with components that are brought together usually when there is a performance issue. Often, we see analytic applications have a solution, but the upgrade takes it out of compliance with the host (Oracle etc) which has yet to release a new version. The compatibility issues lead to a series of performance problems for vendors, after mergers and acquisitions were complete, that resonate to this day. This is where Cloud services really have come into play through ease of use and removal of the upgrade issues that so often took up the time of teams in DevOps.


Architecture can be defined as a blueprint that conceptualizes the structure and operation of organizations. While I felt this used to work I prefer to look at it as the blueprint of operations that are allocated to physical systems to support the business. While it is semantically different it coalesces the idea that you can generate platforms with a fundamental unity to drive business and as long as you manage that fundamental unity you should be able to navigate clearly. This goes against most principles of architecture but I would add that it is much closer to what really happens rather than what you would like to happen. Cloud Architecture has really been the arbiter of change for my definition. Cloud architectures have removed that need to think in terms of hardware requisitions and delivery times to open up a clear focus on how to really get the work done. The discussion has changed to be more about if the platform will need to evolve (hint: it will) or if it is agile enough for what you need to do. Services have added a layer to insulate users from market forces by giving them the choice to adopt real time streaming or AI rapidly. I am often surprised by reviewing cloud based architectures and suddenly seeing the use of technologies that require considerable time and investment when a service could have been called. The use of containers also somewhat promotes the idea of keeping original architectures which I feel works in the short term but is not valuable or part of the economies of scale that could benefit.


To look at the fundamental unity of platforms and be successful you will need to review the core components but remain aware of the peripherals. The peripheral components should be homogeneous to the platforms so that you can extend the idea of platforms into an architecture. Vendors have struggled with the idea of combining technologies to form stable homogeneous platforms because of acquisitions of diverse technologies that are complex to integrate. Cloud architectures offer a good start to really gain competence of your platform strategy as long as you have great cloud management and provisioning software to control the environments. Services take platforms to another level entirely and are often underused because they are often not considered when migrating to the cloud. While definitions are changing for platforms they also are highlighting how powerful a support network they have become.


About the Author



Asim Razvi is the head of data management and data strategy at Onis Solutions with over 25 years experience in delivering world class solutions in data to clients. He has architected some of the largest hybrid data management solutions for the Fortune 100 and also worked closely to deliver Business Intelligence strategy assessments to them as well. He works and collaborates closely with a number of CDOs and maintains a busy schedule of events and speaking engagements. Outside of work he trains outdoors to maintain a healthy lifestyle and spends time with his family in the wilds of the California mountains.


Asim Razvi

Vice President Lead, Data Management

asim.razvi@onissolutions.com

28 views