Recently I’ve been thinking about the relationships among emerging technologies, especially how the various ecosystems fit together. The list of technologies can be lengthy – social networks for people, wireless networks for mobile devices, systems for big data and analytics, hybrid cloud computing, IoT (in various flavours) and various applications of blockchain.
These are the building blocks of a truly major disruption in how IT is developed, deployed and operated. But do we have an appropriate architecture for what we’re building?
In my opinion, few if any of the next-generation technologies have been the result of a structured architecture or an architecting process. Furthermore, traditional approaches to enterprise architecture do not seem to fit very well with today’s open source vendor-driven services.
With the drive for agility, adaptability and continuous delivery, do we even have time for architectural planning, especially when the products and services are hyped so much and changing so rapidly?
An even more basic question, of course, is whether the enterprise architecture process has proven its worth even in the past?
This topic deserves more than one blog, but let’s try to set the scene here and follow up with deeper dives in future posts.
What is an IT architecture?
In the IT world, the word “architecture” is often misunderstood and the process of creating an architecture Is far from being a precise science.
Often a qualifier is used to describe the scope of an architecture; for example, we have enterprise architecture, system architecture, processor architecture, software architecture and network architecture. In an attempt to avoid confusion, other terms such as framework, reference model and even protocol stack are sometimes used.
The scope of an architecture also depends on the context – the business owner, the system engineer, the product manufacturer and the standards developer all have different architectural perspectives.
Some examples of architecture design styles include:
- The Zachman Framework for enterprise architecture;
- TOGAF Version 9.1, the Open Group framework for enterprise architecture;
- The Reference Model for Open Distributed Computing (ISO/IEC 10746);
- Systems and software engineering – architecture description (ISO/IEC/IEEE 42010:2011);
- TRAK Enterprise Architecture Framework; and
- IT4IT Reference Architecture, which focuses on IT management.
One of the “classic” reference models is The Basic Reference Model of Open Systems Interconnection (ISO/IEC 7498).
Gartner uses the following to define the term architecture in general:
- In reference to computers, software or networks, the overall design of a computing system and the logical and physical interrelationships between its components. The architecture specifies the hardware, software, access methods and protocols used throughout the system.
- A framework and set of guidelines to build new systems. IT architecture is a series of principles, guidelines or rules used by an enterprise to direct the process of acquiring, building, modifying and interfacing IT resources throughout the enterprise. These resources can include equipment, software, communications, development methodologies, modeling tools and organizational structures.
Gartner also defines enterprise architecture quite differently:
“Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions.”
Clearly, there is no simple definition and authoritative source for learning about IT architectures.
The hierarchical nature of architecture
An important goal for ISO standards is to get people speaking the same language, in the same way, with the same meanings (even for people whose normal language is not English).
Standards development often starts with a basic vocabulary, then establishes a reference model and finally specifies standards for common services, functions and practices as needed.
This approach has been used to develop standards for cloud computing; download ISO/IEC17788:2014 for a cloud computing overview and vocabulary and ISO/IEC17789:2014 for the reference architecture.
Different levels of architecture description could include:
- Vocabulary: a basic set of descriptive terms and concepts that help to create a level playing field for people to discuss the subject;
- Reference model, framework or architecture: a description of the elements of the subject area at a conceptual level;
- Functional models: a specification for the building blocks that would be needed in an implementation;
- Solution (services/profiles) – a set of the services or functional components that would be required for one or more use cases or for a platform or ecosystem;
- Technology (design/engineering) – the rules and best practices for a technology that is needed for implementation, including processing architectures, network architectures, software architectures, etc.
Again, there is no single way to address all the perspectives that must be taken into account when new technologies are being applied to solve IT problems.
What is changing
I believe that IT architectures need to adapt to the changing industry and recognize the transformation that is now in progress. Some examples:
- Hybrid and public cloud solutions are designed for multiple customers and large web-scale systems, not for a specific “silo” or customized corporate requirements;
- Shadow IT (user’s bypassing the IT Division to purchase cloud services) are typically be outside the architecture process;
- DevOps and other rapid development practices lave little time for formal architecture planning and top down design;
- The use of provider-customer partnerships in the provision of cloud services can complicate the planning and design processes.
This is what I think. Do you have any insights or differing views on the role of an architecture (or the architecting process) in our increasingly complicated world of multivendor, multiuser, multi-technology systems? Let us know in the comments section below