What is IT Architecture? - Quality Thinking

A primer

After writing many blogs and articles about architecture, I realised I needed to explain precisely what architecture is. It was remiss of me as some may need to know, and others may be curious. I am describing it here.

Let’s look at architecture’s origins, value, definitions, disciplines, methods, artefacts, governance, and profession.

Origins

About 10,000 years ago, humans started settling along rivers and farming the land. They left behind caves, rocky outcrops and shelters made of branches and leaves and began constructing mud huts and stone dwellings and invented bricks. The population multiplied, and towns and cities developed that were laid out in some order, with sewerage, religious buildings and administrative offices. As human thought grew complex, pyramids, ziggurats, astronomical structures and elaborate temples were built.

In the early stage of civilisation, adult family members had to work out how to make a base for a hut, walls, windows, and sloping roofs. They could see their larger needs and work out how to assemble suitable things to meet them. They observed that stones were strong, durable and could be shaped; that wood was light, pliable and good for framing; etc. They didn’t care, nor need to care, about what inside the stone or wood made them so. This is the essence of architectural thinking; they were the first identifiable architects. In that sense, whenever we do such things, even now, all of us are architects.

As the population and civil structures increased, so did the need for raw materials, planning and standardisation. Some individuals with a bent for it specialised in directing these aspects and became the first professional architects in every civilisation, e.g., the Indus Valley, Mesopotamian, Egyptian, etc. Some historical architects we know about are Imhotep (Saqqara Step Pyramid), Ictinus (Parthenon), and Ustad Ahmad Lahori (Taj Mahal). Read this for more, including modern greats.

In parallel, the development of religion, politics, government, trade, finance and other human systems needed solutions. Those who conceptualised and guided their overall frameworks were also architects.

About seventy years ago, in the 1950s, we invented electronic computers, networks and data storage to help ourselves. We call this tool information technology or IT. It is a combination of hardware, software and human skills. The wonderful thing is that we can make myriad combinations and forms of the tool to serve millions of purposes. IT Architects emerged as specialists who work out the structure of these morphings. The models they create and use are IT Architecture, whose ghostly outlines we see in the actual systems if we know how to look.

Value

Like most things of value, we expect IT Architecture to provide us with three things.

A solution
A good solution
A cost-effective solution

Any IT Architect can produce a solution, i.e., something that does the job.

A good IT Architect will make the solution easy to use, have the capacity and speed expected, be available when needed, recover from issues, be effortless to manage, and be safe.

An excellent IT Architect will formulate a good solution that is as inexpensive as possible over its life, including initial and running costs.

Architecture is about thinking big picture and long term. Not that we want analysis paralysis, but giving anything adequate thought makes it better. While other activities focus on doing with thinking, architecture’s essential purpose is thinking. Like a pinch of alum magically clears up muddy water, so does a dose of architecture clear the way ahead.

Definition

Like many other words such as seating, drawing, etc., two meanings come to mind when we think of architecture — thing and action.

As a thing

Architecture is a model of the structure of a system in terms of components that are related statically and dynamically through their external attributes. (SSCRA is a mnemonic aide memoire.) The model is a thinking aid and means of communication.

As an activity

Architecture is a vocation that provides practical architectural solutions for an enterprise’s needs and wants while striving to maximise quality and minimise cost. (PASQC is a mnemonic aide memoir.) It has formalised methods, patterns and tools.

An architect is, of course, a practitioner of architecture who produces architecture.

Where do we look for architecture?

Whatever we pause to consider has an architecture. If we think of the universe, we see it has an architecture comprising galactic clusters, galaxies, gases, stars, gravity, and dark matter. Step our mind’s eye downwards to galaxies, stars, planetary systems, planets, continents, countries, cities, houses, furniture, molecules, atoms, protons, neutrons, and electrons — each has an architecture. Finally, we may say there’s no architecture in quarks, leptons and bosons, but we may yet be surprised.

Architecture vs Design

Architecture and design are closely related terms, often used interchangeably. There’s not much wrong with that, but for IT, it helps us to distinguish their subtle differences.

‘Design’ has the feel of looking closely and intently at a single thing, an object perhaps, and working out the details that make it work. ‘Architecture’ has the feel of stepping back and looking at something big, made up of many parts.

This is pretty much how the field of architecture distinguishes the two terms. Whatever is happening inside one of the components of an architectural structure is ‘left to’ design and designers. As long as it has the useful external attributes required by other components, architecture and the architect don’t particularly care about its internals, i.e., its design. This paradigm proves effective for delivering an IT solution with a division of thought and skills between architects and software or hardware designers.

(Of course, if the architect gives her attention to the component, it immediately morphs into a system with a structure and components connected by attributes, and voila, an architecture. But until then, it’s only a black box with ‘some’ design.)

Disciplines

The complexity of Information Technology grew rapidly over the 1980s and 1990s. Specialisations emerged in hardware, operating systems, databases, network and security technologies, coding languages, etc. Defining and building solutions got divided broadly into business analysis, architecture, design, coding, testing and project management.

As the types and numbers of IT users grew, so did the spread, size and complexity of applications, information management, integration and infrastructure. Business architecture became intricate and required specialised skills. An enterprise architect became essential for bridging business and IT and planning IT’s alignment with long-term business drivers.

These main architecture disciplines are described below. Of course, there can be other categorisations, but this set works well.

1. Application Architecture

Applications are the central unit of functionality in the IT landscape. They may also be called systems, sub-systems, or software. Application architecture defines how business or technical functionality is delivered by dividing the application into components that interact with humans or other systems, store and retrieve data, represent and execute business rules, etc.

Typical patterns of Application Architecture are — client-server, layered, model-view-controller, mobile, microservices, etc. E.g., the architecture of a sales application, customer relationship management application, HR application, dealer management application, reporting system, etc. (Please see this article for more →A Practical Abstraction of Functional IT Systems)

2. Information Architecture

All IT is about writing and reading information back as-is or transformed for various uses. Information architecture defines how the information will be stored, denormalised, copied, altered, accessed, queried, joined, retained, backed up, purged, protected, etc., for applications. Information architecture has the most significant impact on the cost and performance of IT systems.

The information architect uses architectural patterns such as hierarchy, database, linear, catalogue, etc., to provide the functionality and quality required by the users. (Please see this article for more →Enterprise Data Repository Patterns and Progression)

3. Integration Architecture

Systems need to talk to each other, and information needs to be exchanged between repositories. Integration architecture considers the characteristics of the clients, servers, requests, responses and payloads to provide the best mechanisms to connect the functionality of the applications and information.

Some typical integration architecture patterns are messaging, queueing, publish-subscribe, broker, orchestrator, etc. (Please see this article for more →Enterprise Integration Architecture Patterns)

4. Technology (Infrastructure) Architecture

The servers, racks, storage systems, network equipment, security devices, backup gear, data centres, power supplies, air conditioning, middleware, management systems, etc., that run the IT software must also be architected.

Technology design is often neglected as a proper and mainstream architecture discipline. This situation has worsened with cloud computing and paradigms such as ‘serverless’. The inevitable result — issues in capacity, performance, availability, resilience, security, etc. that are handled reactively and expensively. So we cannot deprecate the architecture method, artefacts, patterns and governance for the infrastructure solution. Technology architecture is a vital and integral discipline and step in SDLC’s architecture design phase.

5. Business Architecture

Business and non-business enterprises need to be designed to work well. Business Architecture formulates an appropriate structure for the organisation to meet the needs of its products, services, customers, suppliers and the external environment in which it works. It delivers tactical and strategic business architecture solutions through static and dynamic business models.

Some of the aspects considered by a business architect are the functional capabilities required for the value streams (vision, strategy, tactics, products and services, initiatives and projects) of the enterprise and the information (metrics and measures, events and decisions, policies, rules, regulations) and organisation (domains, sub-domains, stakeholders, human and other resources, hierarchies) they need.

6. Enterprise Architecture

Enterprise architecture is the highest and broadest of the architecture disciplines. An enterprise is any value-producing organisation, from the smallest to the largest, that makes money or is philanthropic, administrative, recreational, political, public service, etc.

Enterprise IT Architecture provides the linkage between business strategy and information technology. It shapes IT to enable business holistically, tactically, and strategically. It delivers this through Enterprise IT Architecture (the models), Gap Analysis, Transition Plans, and Architecture Governance. Like other architecture disciplines, it delivers functionality, quality and efficiency, but at the level of the enterprise. An enterprise architect works with the business leaders and stakeholders, discipline architects and IT partners to deliver the enterprise architecture. (Please see these articles for more →A Technique for Agile Enterprise Architecture Strategy & Planning, How To Do EA Fit Gap Analysis To Fix Problematic IT Systems, and How to become an Enterprise Architect in 4 stages)

Method and artefacts

The general method of creating an end-to-end solution architecture is briefly described below. As this article is an introduction and primer on architecture, elaborating on each step and its artefacts is beyond its scope. Architects entering the profession and practitioners who need the details should get full-fledged training from a reputed architecture organisation that typically lasts several days. Please take a look at the Profession and Career section below.

Once you have gone through this section, I strongly recommend following Domain-Driven Architecture Design for each step, as described in these articles →Domain-Driven Architecture Design for Excellent IT Systems-I-Introduction and Domain-Driven Architecture Design for Excellent IT Systems-II-Primer. (As this is a generic architecture article, DDD terminology is not used here.)

Please note that for large and complex programs, several architects could be involved, including Enterprise Architect (EA), End-to-End Solution Architect (SA), Application Architect (AA), Technology Architect (TA), Integration Architect (IA) and Information/Data Architect (DA), and Business Architect (BA).

1. Requirements Gathering

Business Use Cases — The most unambiguous and architecturally elegant way to capture business requirements is through Use Cases. There should be one use case for each discrete and complete business task. E.g., Log in, view past orders, raise a complaint, etc.

For each use case, detail the functional requirement (FR) as a sequence of steps with information on the pre-conditions, actors, user interfaces, events, actions, data entered, read, modified, deleted, healthy and error pathways, and post-state, etc. For every unique response, capture the non-functional requirements (NFR) (e.g., capacity, latency, availability, etc.). Common NFRs can be put down in one place at the end (e.g., growth, security, etc.). Do this for operations use cases too. Ensure all the actors and functions in the scope of the solution are covered across all business domains.

Use cases vary from simple to complex. If the text description does not suffice, add process flow and interaction diagrams in the use case.

Please see this example below of a verbal use case description (the second and third use cases are incomplete).

Context Diagram —It is drawn to show the external human and IT systems with which the solution needs to interact but are not in the solution scope and can be assumed to remain as they are. This is the context or environment of the solution. It helps in defining and limiting the solution. Put an oval for the solution, connect the external actors and systems to its outline, and briefly put what happens on each connector.

Please take a look at this illustrative diagram.

EA Policies, Principles, Guidelines and Standards — Gather these from the Enterprise Architect or CIO/CTO. These are also requirements or constraints that the solution architect needs to fulfil. Please see the governance section below for more about this.

Constraints — Collate the dependencies on other projects, finance and time restrictions, skills constraints, technology limitations, etc. Update this information as the architecture is developed. An acceptable solution must take these constraints into account.

2. Architectural Decisions

Architectural decisions represent the essential rationality and intellectual humility of architectural thinking. With an open mind, the architect works out how the business functionality will be spread across software and hardware components and operated. Making sound architectural decisions is the most excellent skill of the architect and decides the overall solution and its success.

There are four steps in making architectural decisions.

Collect the relevant reference architectures and architecture patterns
Convert the business requirements into architectural problem statements for function placement, data repository/source, and integration method. (See this article for more on this →The 3 Most Powerful Architecture Decisions (10 min podcast))
Let the reference architecture and architecture patterns provide as many decisions as possible that make sense. E.g. for the problem statement ‘From where shall the checkout component get the order delivery time?’ let’s say the reference architecture shows a suitable API on the logistics system; that could be the decision.
For the rest of the problem statements, use an Architecture Decision Template to state the problem, list all reasonable solution options taking constraints into account, select the best one, justify it, and capture its implications for technology, other decisions, designs, etc.

Please take a look at the AD template and example below.

3. Architecture Overview

Once you have the context diagram and make the architecture decisions, you have everything required to draw the basic model of the solution and describe it.

Architecture Overview Diagram — Draw this at two or three levels for different audiences. E.g., For Business Leaders, make a Level zero or L0 diagram showing the technology areas that will deliver the business requirements; For Project Managers, make an L1 diagram showing the systems and sub-systems and their broad connections that will need to be delivered. (See this article for more on this →How to draw epic IT architecture diagrams)

Architecture Overview Description — For each overview diagram you create, briefly describe each item’s role, and interaction with others for the main business and operations use cases.

Here is an example L1 diagram showing major business capabilities and the underlying IT systems.

4. Functional Architecture

The functional architecture phase elaborates on the components, and sub-components of the systems and applications decided earlier in Step 2 for delivering the business and operations use cases. In specifying the components, the architectural principles below catalyse ease of development and maintenance. Following them saves time and reduces the cost of IT solutions significantly.

Reuse — if an existing component is architecturally sound and has all or most of the functionality, use or extend it. E.g., if there is a directory component for authentication of users, reuse it. If it doesn’t have the requisite hierarchies, extend it.
Cohesion (and granularity) — a unifying purpose or concept should define an architectural component so that it contains methods and data which belong together. This enables clean segregation and independent development of functionality. A related aim is to achieve the right level of granularity for a component, which is the number of functions assigned to a component. It should neither be too small nor big, i.e. it should neither do too little nor too much. If there is one thing that a skilled architect gets right, it is cohesion and granularity. It lies at the heart of good architecture. E.g., credit risk scoring data and APIs should be in a credit-risk component, separate from a loan-approval component with the overall loan approval data and APIs. But if the loan-approval component grows too big, as in a typical banking operation, it should be split into underwriting, loanfunding, qualitycheck components, etc.
Loose coupling — architectural components should not require knowledge of other components’ internal data structures and rules. This allows changes in components that don’t affect the design of other components. E.g., If component A needs to work on the aggregate value of items held by Component B, with loose coupling, Component B will have an API operation to provide the aggregate to Component A. Even if Component B’s internal design changes, it will not affect Component A’s design. In the (deprecated) situation of tight coupling, Component B will have no such API. Component A will need to know how many items Component B holds and how to get each and aggregate their value. If Component B’s design changes, it forces a change in the design of Component A.

L2 and L3 Architecture Diagrams —Once you have decided on the functional components and APIs, you have everything required to draw and describe the next level of the solution. For other architects, business analysts and development team leads, make an L2 diagram for each system of the L1 diagram, showing the components and APIs. L2 diagrams are the most important and usual ones drawn by architects. For software designers and testers, make an L3 diagram for each component showing its sub-components and their interfaces that must be coded. An L3 diagram loosely corresponds to the application software’s object classes, interfaces, and database tables and can be developed with or left to the software designers. (See this article for more on this →How to draw epic IT architecture diagrams)

Here is the illustrative L2 architecture overview diagram for the promotions system of the L1 diagram in section 3 above. Make one for each system of the solution.

Sequence Diagrams — Once the architectural components are clear, map them to the business (and operations) use cases by drawing sequence diagrams that show their dynamic interaction. The vertical axis is time; one line is drawn for each component vertically, and the actions progress from top to bottom.

Here is an example of a donation use case sequence diagram.

Component Specifications — The sequence diagrams will help remove gaps in the responsibilities assigned to components and sub-components. At this point, verbalise the data and operations specifications of the components and sub-components of the L2 and L3 diagrams. This may result in changes to the diagrams, so work iteratively.

Interface Specifications — The sequence diagrams will help remove any gaps in the interfaces of the components and sub-components. At this point, you can finalise the interface specifications (at an architectural level, their exact design, error handling, data payloads, etc., should be left to software designers and developers).

Information Architecture — Similarly, the sequence diagrams will help remove discrepancies in the information responsibility of each component and sub-component. At this point, you can capture the information architecture of the overall solution.

Integration Architecture — With the components, interfaces and information repositories decided, their integration needs can be addressed. Integration can involve several functions such as messaging, queuing, publish-subscribe, routing, aggregation, orchestration, protocol and object transformation, security, etc. This is a large area of architectural thinking. (Please see this article for more on this →Enterprise Integration Architecture Patterns)

5. Operational Architecture

The operational architecture stage determines the required hardware, operating systems, networks and middleware (e.g., application servers, integration systems, databases, etc.). We can justifiably consider that operational architecture most fulfils the Non-Functional Requirements such as capacity, performance, availability, scalability, resilience, manageability, business continuity, etc. However, we should remember that the application, information and integration architectures also play a significant part in the NFR solution. (Please see this article on availability as a deeper example of operational architectural thinking→How to Calculate and Design IT Service Availability.)

Operational architecture determines the technological components’ size, instances, versions, distribution, connection, etc. It can specify new infrastructure or the existing infrastructure’s extension and reuse.

Here are some of the main aspects considered by operational architecture.

Deployment Architecture—Here, the infrastructure architect determines what is required as per the nature of the software component. Listed below are some of the significant aspects that are worked out.

Providers and specifications of the selected ready-to-use services. E.g., payment gateways, credit check service, geolocation service, etc.
Location of all the software components in own or partner private data centres or public clouds
Server physical/virtual cores, RAM, and OS
Network architecture, including LAN, WAN and external connectivity and capacity, appliance locations and sizes
Storage type and bandwidth
The distribution of software and hardware in chassis, frames, racks, etc., as per the availability architecture
All the above for middleware components, e.g., HTTP servers, web servers, integration systems, logging and monitoring systems, etc.
Backup and restore and disaster recovery solutions

Security Architecture — Security has many dimensions, e.g., access control, privacy, information security, threat protection, etc. The infrastructure architect applies security frameworks and standards to determine what needs to be protected in application layers, integrations, data stores, and hardware to define the security architecture. (Please see this article to familiarise yourself with various aspects→How to Assess the Security Maturity of an Enterprise (an EA’s PoV))

Operations Management Architecture — Managing IT operations cannot be an afterthought for the architect. It has to be run by humans and automation continuously for many years. The starting, stopping, updating, monitoring, scaling up and down, error handling, backing up, restoring and many other aspects of a live system need systems and well-defined use cases, processes and workflows. The technology architect must ensure that these are detailed rigorously by the business architect or analyst. The architecture should be worked out, the artefacts created, and the solution guided and validated. E.g., end-of-month reporting process, quarterly data purge process, incomplete transactions clearance process, etc.

6. Solution Validation

Solution validation ensures the architecture delivers value by stepping back and taking stock of the solution’s quality as it is designed, built, tested and operated. And the architect observes the short and long-term results and learns and improves the solution.

For solution validation, the SA relies on the following.

Internally — Traceability Matrices that map requirements, architectures and designs to corresponding tests and testing outcomes. E.g., business and operations requirements are mapped to user acceptance tests, sequence diagrams to string tests, interface specifications to integration tests, functional design to system tests, code to unit tests, NFRs to performance tests, and so on.
Externally — the Design Authority (see the next section).

The overall method is illustrated at a high level below.

Governance

Architecture needs to be mainstream, mature, monitored and managed to derive its benefits. The following four aspects are essential for this.

A. Make architecture a part of the enterprise and its initiatives

Since the advent of IT software and systems, the urge has existed to go straight from requirements to coding. It worked while things were small and simple, but it hasn’t for several decades now.

Architectural thinking is essential for our challenges today in bridging complex and rapidly evolving business needs to technology.

The starting point is ensuring the enterprise’s leadership understands and demands the value of architectural thinking, from enterprise architecture to other disciplines.
Capture the current architecture of the business and technology.
Make architecture checkpoints (or gates) part of every tactical and strategic change process.

The diagram below shows the typical enterprise change life cycle with architecture review gates for the ARB and DA (see section C below) that are opened after verifying the solution’s completeness and quality.

B. Establish an architecture practice

The next thing to do is get the right architectural competency. This has three dimensions.

Method — A systematic way to determine the solution. We have seen the general architecture development method above.
Skills — Having the right people for it. We have seen the architecture discipline skills above.
Artefacts — Having effective and consistent tools for the method and practitioners. The architecture method above showed the key artefacts. But there are several more for each architecture discipline and stage.

Internal IT departments of companies, where they are responsible for solutions, should have an enterprise architecture practice supported adequately by discipline architects. This delivers tremendous value tactically and strategically for the enterprise.

Services companies like application developers, system integrators, product companies, web service providers, and managed services companies must have an architecture competency led and staffed by experienced and certified architects. It is an investment that pays off by generating business through effective client technical engagement and delivering satisfactory and profitable solutions.

C. Establish governance bodies

The two primary architecture governance bodies are the enterprise Architecture Review Board and the project Design Authority.

Architecture Review Board (ARB)

The ARB is the primary architecture governance body for aligning business with technology at the enterprise level. It is chaired by the CIO/CTO and Chief Enterprise Architect and comprises enterprise architects, discipline architects, business stakeholders, finance heads, chief security officer, and others as required. The ARB does the following.

Provides enterprise architecture directions
Approves architecture initiatives
Oversees the work of the project Design Authority (see below) and resolves any issues brought to it.
Liaises with the business community and gets stakeholder buy-in
Formulates policies, principles, guidelines and standards that provide speed, efficiency and quality by avoiding reinvention and incompatible or ill-fitting systems. They are defined below.

Policies dictate how things will be done in different aspects of architecture and technology (mandates). E.g., All digital solutions shall be provided by partner x.
Principles reflect the intentions of the enterprise and help to decide broad directions (recommendations). E.g., Open source solutions will be adopted wherever possible to reduce cost and encourage the open source movement.
Guidelines help to decide minor questions (advisories). E.g., B2B integrations should be done via the Enterprise B2B Integration Gateway.
Standards enable repeatability, speed and efficiency (decisions). E.g., All APIs will be based on TMForum Open APIs.

Design Authority (DA) or Solution Review Board (SRB)

The Design Authority ensures that general and enterprise-specific architectural practices are followed by every project and helps the solution architect with decisions and issues. An Enterprise Architect chairs it with a panel comprising experienced discipline architects, IT department heads, program managers, operations managers, and other stakeholders. The solution is represented by its solution architects, business analysts, project managers, and development and test leads.

The DA does the following.

Develops and maintains enterprise-level architectures
Conducts architecture reviews with project teams
Advises and mentors project teams in all areas of architecture
Acts as the representative of the enterprise ARB
Identifies and resolves issues and escalates to the ARB when necessary

D. Manage enterprise transitions architecturally

With gating, skills and governance bodies in place, apply them through the organisation’s program management office or other oversight bodies to three levels of change:

Formulate enterprise-level IT Strategy & Plans (S&P) based on business drivers for the one to three-year timeframe
Guide IT projects shortlisted for delivery from the above strategy and planning process
Manage business-as-usual changes in existing IT systems

Profession and Career

Don’t just call yourself an architect. Learn architecture, practice it for at least 80% of your working time, follow the method, deliver the artefacts, and certify. It’s easy, especially if you love and enjoy architecture, rather than doing it only for its cachet or pay.

Learn

Some large global IT services companies (surprisingly few) have architecture as a defined career path and provide in-house or affiliated architecture training. If you belong to such a company, get its training. If not, look for courses online. Or contact me after August 2024, when I may start my training course. (You can learn a lot by reading books and articles, as you should. But beware, don’t start thinking some mish-mash you imbibe is architecture.)

Practise

You’ve got to do it to get it and be it. This applies to architecture too. Look for projects where you can be the lead or supporting architect. Make sure it’s one where the rest of the team and management understand the value and necessity of architecture. Follow the method and deliver the artefacts. Understand that everyone is a customer of the architect to varying degrees and interact with them to gather the requirements and constraints and communicate the architectural thinking — the business, BAs, PMs, designers, coders, testers, operators, other architects, and partners.

Traits of an IT Architect

IT Architects work with the widest variety of people. They have to get information out of many, convince and cajole others, and take everyone along. Due to this, they have or acquire the traits of effective communication, integrity, humour, influence, a methodical approach, and leadership. Extensive general knowledge, an interest in current affairs and global trends, and a philosophical bent help them see and show the big picture.

Certify

The most generic and widely accepted certification is that of The Open Group. If your company has an internal architecture certification and you do not intend to leave soon, get its certificate. If it’s affiliated with Open Group, you may get OG certified too. If your company doesn’t certify architects, do the Open Group certification. Alternatively, you can get the credentials of such companies as Microsoft, Google, and Amazon. But these will be specific to their technologies and architectures and are not portable or effective for technology-agnostic solutions.

Career pathways

Like in other professions, it is more natural to go from working on the smaller perspective to the larger and from depth to breadth. Experience in coding, design and technology makes a good architect. Experience in another architecture discipline makes a good enterprise architect.

Some typical career pathways in architecture in order of occurrence and smooth transitions are listed below. Of course, there can be other sequences and endpoints. It is for you to work out how your interest sustains or evolves.

Coder →designer →application architect →integration architect →enterprise architect.
Coder →designer →application architect →information architect →enterprise architect.
Technology specialist →infrastructure architect →enterprise architect.

End note

Given the impact of information technology on humanity, IT architecture is a vital profession. It’s poorly understood, and it can be difficult to convey its value to others, despite the Old Testament making God an architect, Hinduism having a god of architecture named Vishwakarma, and so on. It’s up to us to understand it, deliver its value, and teach it to others.

It would be my great pleasure to help you on this journey, and take your help if you’re more skilled and wise an architect than I am.

Home

Shashi on LinkedIn, Medium, FB, Twitter