Intuitive Software Architecture (iArchitecture)
The Architecture
Before starting this interesting journey, we need to talk about the word “Architecture” which is more related to the buildings (and other civil structures) to describe the design, the planning, and the construction of a static and tangible piece of art.
On the other hand, the most tangible part in software architecture is the deployed end-user applications which are used to manage the flow of data on different app pages/screens. That tangible part of software architecture could be representing 20% (less or more) from the whole architecture, it is like iceberg. The rest of architecture lies in the hidden part managing the backend tasks and the integration with other architectures to conform an endless ecosystem.
While the classic building architecture is relaying on a static infrastructure, the software architecture is relying on a dynamic and flexible infrastructure.
Actually this is not a comparison between building architecture and software architecture, we just need to capture the shared concept between both and the vocal point, which is “making a design decisions to create an artifact”. The way still similar as blueprints still used to model the final artifact.
The Concept
In the following sections, I’ll tell you some architecture concepts based on my work experience and what I have learnt about software architecture frameworks and methodologies. Some concepts like “Architecture Dimensions” is coined and used from my side to make a clear seen for what I am going to do, and to be like a compass that guide me to the target output. While the other concepts (used here) are standard concepts and already used by the software architecture community like “Architecture Views”.
The Art
Art is a diverse range of human activity, and resulting product, that involves creative or imaginative talent expressive of technical proficiency, beauty, emotional power, or conceptual ideas. (Wikipedia)
It is clear that the software architecture is an art, that means it is requires talent and knowledge.
The art of software architecture still rising and still in the formalization stage. I mean, there are no solid boundaries set for software architecture yet, but what is clear for us right now is the significant impact of software architecture in our life by creating new bonds between us (and machines) mixing reality and virtualization. It is really making a big change in people life.
It is not only an art, as there are a lot of things you have to learn when you get in touch with the real world of people, technologies, and culture so there is a need to learn from others and also from your own experience as you go.
It is worth to learn the standard architecture frameworks and methodologies as a foundation of your way, TOGAF is much recommended as the most comprehensive architecture standard.
The Dimensions
As mentioned early, I am using architecture dimensions to identify the boundaries and the target output (deliverables).
The output of architecture process is determined by the dimensions of scope, view, and the level of details. These three dimensions formulate a wide range of architecture artifacts that can be delivered and by then emphasize the different architecture roles as per each target deliverable(s).
I am using these dimensions to allocate the target artifact in the architecture matrix, each dimension could be described as follows:
1. Scope — refers to the scope of architecture like organization, program, application, or it could be a specific technology scope (e.g. platform, DevOps, infrastructure and network, azure, aws, etc.)
2. View — refers to the perspective of the architecture design like business view, logical view, application view, data view, physical view, and/or any other view which explain the idea of architecture from a specific point of view as per stakeholder's matrix.
3. Details Level — refers to the level of details required for each architecture scope and architecture view like high level details, low level details, or high level for some parts and low level for others as per each case.
That will be explained in detail in another article
Roles
There are many architectural roles that can be defined for software architecture. actually, there are a wide range of shades when talking about the role of architect, and there is cross-section between roles and each other too.
Lets take the benefit of architecture dimensions to identify the boundaries of different roles and their purpose. starting with “Scope” dimension which is the clearest dimension that can be used to describe the architecture roles, we can see that we have technology based roles, application based roles, program or industry based roles, and organization based roles. The other two architecture dimensions are almost used to identify the anticipated output with each role.
I like to categorize architecture roles under three main roles as follows:
1. Enterprise Architecture
2. Solutions Architecture
3. Technology Architecture
What is worth to mention here is that the architect can move between roles or can play many roles, and that really cause an issue to identify the role of architect inside the team or organization
That will be explained in detail in “What are The Software Architecture Roles” article talking about architecture roles as depicted in the following diagram
The Processes
These days we can see that the makers of software applications are looking a practical and efficient process which is nimble and adaptable for the organization and the market.
Intuitive Architecture is adopting an iterative process pattern of act (design), collect (feedback) and evolve (mindset and content). the whole framework is not only an iterative flow but also it is a pattern of independent layers that integrate to formulate the big picture.
Methodology — TOGAF is the most advanced architecture methodology and in somehow I am influenced by TOGAF as a standard and and as an educational reference so e.g. Architecture Views here is matching TOGAF ADM domains.
Framework — current agile frameworks like SAFE, LESS and DAD are really adding value in software development as a discipline for the entire process. I am specially impressed with DAD as I like the ideas behind it like flexibility to be adapted in the way that support the target goals and its focus on people and mindset
Intuitive Architecture is a light methodology and framework, it is not only focus on the technical side but also consider processes, people, and mindset side.
The Mindset and the team culture
Mindset could be the focal point in Intuitive Architecture as it is leading the evolvement of methodology principles and framework continuously.
An educated and unified mindset is relay helps rapid organizations development and prosperity as it controls the behavior and the target output.
That was an introduction for the roadmap of an amazing journey that will excite your mind with questions and debates, the fun just started!
