Being an Architect

Why Being an Architect, not Becoming an Architect?

Being is part of the essential nature of some abstract entities. They are ideas that exist in the immaterial realm of pure information and do not change. Becoming is the essential nature of concrete material objects, which are always changing. Change in space and time is a characteristic of all concrete material objects. Some abstract immaterial entities also change, like the time of day. Only those abstract entities that do not change in time are those with “Being.”

The Goal of Architecture

Grady Booch offers a concise and succinct definition of software architecture in his Handbook of Software Architecture. The definition is as follows: “The architecture of a system is the naming of the most significant design decisions that shape a system, where we measure significant by cost of change.”

The Goal of Architecture Is Cost-Effective Evolution

The significant decisions are those that, if made incorrectly, result in an inability to achieve our architectural goals. Therefore, the goal of software architecture is simple — to create systems that meet the operational needs of today while possessing the ability to adapt and evolve to meet the needs of tomorrow. Unfortunately, traditional approaches to software architecture do not emphasize this sort of software evolution, and realizing the goal is a bit more difficult.

Examples of failure are easy to find. Consider the following common scenarios:

• Move an application to the cloud: Development teams architect applications and services as monoliths that do not possess the ability to take advantage of cloud platforms (that is, elastic scale). Yet teams architect the application for scalability, which is a benefit of cloud.
• Build a mobile front end to an existing application: Development teams architect applications and services using specific patterns (for example, layering) so that they can build new user interfaces atop existing capabilities, but find doing so is cost-prohibitive. Either the application doesn’t offer an API that mobile apps can consume or services don’t expose a useful restful APIs.
• Migrate to lighter weight infrastructure: Development teams use portable technologies so they have the opportunity to “write once and run everywhere” yet find many impediments that prevent them from moving to a lighter weight infrastructure that is easier to manage.

Fixing these types of problems demands that development teams identify more effective ways that allow the architecture to evolve as needs change.

Architects that practice big architecture upfront (BAUF) make the most important decisions early in the life cycle. The result is a flawed architecture that fails during implementation because it cannot evolve.

BAUF is Flawed

As change occurs, the software system naturally evolves. But with BAUF, the architectural vision remains static. As the implementation deviates from the architectural vision, the architect’s perception of the software system isn’t consistent with the implementation that developers understand. Architects and developers eventually experience communication problems that create a contentious relationship. Architects are focused on the breadth of the system and on establishing the vision. Developers are focused on depth of specific areas of the system and provide the implementation. If these two have different perceptions of the software system, it is not possible for them to have a meaningful conversation on areas of the system that must evolve. Software developers refer to this phenomena as the Ivory Tower. To bring down the tower, teams must focus on the following:

• Increase the architect’s transparency into implementation: Architects must utilize practices that give them greater transparency into the implementation as it is being created by developers. By increasing transparency, the architect can work with the development team to identify areas where the architectural vision is failing, and make the necessary adjustments. Fundamentally, architects must be involved with the implementation throughout the development life cycle and arm themselves with knowledge that increases transparency into the implementation so they can identify architectural deficiencies.
• Increase the developer’s understanding of vision: Developers must have a better understanding of the architectural vision so they can create an implementation that aligns with that vision. In situations where the development team struggles to create an implementation that aligns, they work with the architect to make the necessary adjustments to the vision.

The Three Pillars of Architecture

Increasing architectural agility — that is, creating a software architecture that can adapt to change — requires that development teams get frequent and accurate feedback that emphasizes these three fundamental aspects as shown in below:

The social pillar focuses on practices that help architects and developers collaborate more effectively to ensure they quickly identify architectural deficiencies and can formulate a refactoring strategy. For any large and complex software system, each will always view the system slightly differently. Architects focus on the breadth of the system, with the goal of ensuring that the system as a whole maintains a high degree of integrity. Developers will focus more on the depth of the system, paying more careful attention to the details of specific areas of the system.

Though BAUF does not work, it is still imperative to establish the architectural vision of a software system early in the development life cycle to serve as a guide for the development team. However, teams must also recognize that this vision will adapt and evolve throughout development. As a result, agile architecture allows the architecture to continuously evolve throughout the development life cycle. If the architecture of the system must continuously evolve, it is imperative that the software architect be involved throughout the duration of the project. No longer can the architect establish a vision, hand that vision off to the developers and move onto another project. Architects must be present throughout development and work closely with the development team to continuously refine the software architecture throughout the software development life cycle.

The structural pillar emphasizes creating software with structural integrity. At the most fundamental level, the structural flexibility of the system begins with the structure of the source code itself. This is where dependencies initially manifest themselves and these dependencies roll all the way up to the higher-level structures within the software system. The structural pillar must emphasize managing dependencies and possess the ability to adapt to meet future needs. To increase structural agility, it is not necessary for teams to adopt completely new architectural paradigms. Instead, it is imperative that teams understand the fundamental characteristics of these paradigms so they can be applied to other architectures. For instance, microservices increase agility by confining the scope of change to a single service. Development teams can take a similar approach by creating a modular monolith or coarse-grained services too.

Principles for Increasing Architectural Agility

To increase architectural agility, software development teams must change how they approach software architecture. The practices they employ must address the three pillars and the practices must span several architectural patterns and paradigms. The three pillars are also dependent on each other and teams cannot increase architectural agility by focusing on only a single pillar; they must focus on improving all three. Teams must also be wary of adopting new architectural paradigm, such as microservices, and expecting the paradigm to naturally increase architectural agility. Though it may increase agility, failing to understand the deeper root cause of fragile architecture will result in a different set of challenges emerging. For instance, one benefit of a microservices architecture is the degree of autonomy that service teams have when choosing their own implementation technology and working in relative freedom from other teams. But if choosing microservices solely for this reason and failing to factor the level of automation necessary, along with the modern infrastructure requirements, even greater challenges will surface. Using a set of fundamental practices, teams can address this challenge without completely revamping their architecture, infrastructure and processes, which is an expectation of microservice architecture.

Prove It With Code

Any architectural decision made that isn’t proven with code is purely speculative. You will make assumptions that the vision will translate into an implementation that meets the current needs, but you cannot be certain until you demonstrate a working proof of concept. The proof of concept is binary; it proves that your architecture has enough merit to proceed and removes any room for interpretation. The proof also gives the development team the foundation necessary to evolve into a fully functional final product. That’s architect job.

Architect All the Way Down

The simple sample application on GitHub pays very careful attention to relationships at many levels of the application. While quality source code and class relationships were emphasized, so was the package and module relationships. Placing an emphasis on these higher-level language constructs is a primary reason why the system demonstrates the structural agility to be deployed as a modular monolith as well as some of the functional areas as microservices. View the project’s main readme file for additional information. That’s architect job.

Generate Documentation

Your architectural vision is manifest and proven with code, and the code is the authoritative design specification that will always reflect the system in its current state. But for large software systems, where no single individual can possibly have a deep understanding of the entire codebase, the code is not always the most effective way to understand the software system. Generate some useful diagrams from your code, there are various maven plugins that helps you to generate different diagrams.

Validate and Enforce the Architecture

Proving your initial architectural vision with code and ensuring that the vision survives change are separate issues. In many cases, the code you create to prove your architecture will serve as the starting point for the code you’ll eventually deploy to production. However, production code requires a much higher degree of quality, such as effective error and exception handling. As your codebase grows, you have to continuously validate that the implementation still realizes the architectural vision — you need to continuously demonstrate and prove that your architecture is still working. Consider the following examples:

• Development teams may write code to prove that a preferred approach falls within the acceptable performance parameters, and the code may initially demonstrate it does. But as the system evolves, they must continually validate performance.
• Development teams may write code to prove that a preferred approach allows us to deploy a service to an on-premises legacy app server as well as PaaS. But as the system evolves, they must continually validate this portability.
• Development teams may write code to demonstrate initial transactional demarcation for a common piece of code shared across two systems is working. But as the system evolves, they must continually validate transactional correctness.
• Development teams may write code that demonstrates a layered application composed of services support both a web and native mobile front end. As the system evolves, they must continuously enforce that undesirable dependencies do not creep into the system that violate the preferred layers.

Refactor Mercilessly

Refactoring is the process of improving your existing code without changing its behavior. Refactoring improves the nonfunctional attributes of your codebase, such as overall code quality to improve readability, and helps you manage the technical debt that increases maintenance cost and hinders your ability to understand the software system. Architectural refactoring emphasizes continuous improvement of the architecture as the system needs to evolve.

Keep It as Simple as Possible

There is a strong tendency to design software that exhibits as much flexibility as possible. This tendency is natural; flexible software has the ability to change more easily than inflexible software. Software that can change to meet the test of time survives longer than software that doesn’t. Ironically, however, flexibility is a paradoxical attribute. A quote from Ralph Johnson4 sums it up nicely by stating: “Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change.”

All Types of Architect Profiles

Ralph Johnson once famously state that software architecture is about “the important stuff (whatever that is).” Though several definitions of software architecture exist, the common thread of each definition is that software architecture focuses on making the important decisions that, if incorrect, can take a lot of time, resources or money to rectify. Because of the importance of architecture, it’s also no surprise that several different forms of architecture have emerged over the past several years. Today, there are numerous architectural roles within an organization, and this proliferation of architecture confuses the responsibilities of individual roles.

• Enterprise architect. The enterprise architect is responsible for leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. The enterprise architect role leads, prioritizes and develops the overall enterprise architecture (EA) discipline for the enterprise, in conjunction with the other EA roles, as well as with business and IT leaders. An enterprise can be a business unit, an entire corporation, a government agency or a collection of businesses joined together in a partnership.
• Business architect. The business architect is accountable for proactively and holistically leading or supporting EA activities that create deliverables that guide business models, people, process, organizational change and investments in response to disruptive forces and toward achieving targeted business outcomes. Business architects must be capable of practically applying existing, new and emerging technologies to new and evolving business and operating models. They must also be able to understand, monetize and operationalize new technologies. The individual in this role develops deliverables that are valuable to the business, including business capabilities, business requirements and workflow. This individual is responsible for facilitating the construction of business models, which may include business capabilities, functions and processes, and organization design, as well as working collaboratively with business strategists, process owners and subject matter experts. The role focuses on business strategy and targeted business outcomes — clarifying strategic intentions, identifying business outcomes, exploring implications, impacts and risks, and addressing stakeholder questions.
• Information architect. The information architect strengthens the impact of, and provides recommendations on, business information that will need to be available and shared consistently across the company through the identification, definition and analysis of how information assets drive business outcomes. Responsible for discovering the data and analytics requirements for information for all uses.
• Technical architect. The technical architect is accountable for creating deliverables that guide the direction and development for technological responses to disruptive forces, and driving targeted business outcomes. Technologies may include data center, infrastructure, cloud, mobile and IoT technologies. Technical architects provide the leadership, facilitation, analysis and design tasks required for the development of an enterprise’s technical architecture. They create deliverables that help develop target-state guidance (reusable standards, guidelines, individual parts and configurations) for evolving the technical infrastructure across the enterprise to enable business strategy and deliver targeted business outcomes. They facilitate and orchestrate the delivery of targeted business outcomes through technical decisions.
• Solution architect. The solution architect is accountable for delivering a portfolio of solutions in response to disruptive forces, and driving achieving targeted business outcomes. Solutions include systems (including applications, technologies, processes and information), shared infrastructure services and shared application services. Solution architects provide the necessary leadership, analysis and design tasks related to the development of an enterprise’s solution architecture. This individual creates deliverables that help develop a direction for managing the organization’s portfolio of “to be” and “as is” solutions. These include systems (meaning not just applications, but also processes and information), shared infrastructure services, and shared application services and components to better match targeted business outcome objectives. Solution architecture is sometimes used interchangeably with application and infrastructure architecture. They facilitate and orchestrate the delivery of targeted business outcomes.

While there is overlap between the responsibilities of the software architect and each of these other roles, each role also has distinct responsibilities. For instance, in none of the definitions above do the roles focus on structuring the software system to accommodate evolution, a primary responsibility of the software architect. Software architects might also specialize in certain areas, such as mobile, restful services or front-end architecture.

The software architect must collaborate heavily with other architects in the organization. Here is a sampling of how the software architect role relates to these other roles via a sample use case:

• Enterprise architect: How does a business outcome to increase and improve customer self-service for auto insurance products change and impact our IT investments in relation to other priorities?
• Business architect: What are the internal and external business processes that need to change to improve customer self-service for auto insurance?
• Information architect: What information gets used, and how, to enable an improvement in customer self-service for auto insurance? How is that information made available to other outcomes?
• Technical architect: What common hardware and software is used to improve customer self-service for auto insurance? What new hardware or software is needed to achieve the desired business outcome while ensuring the system meets reliability, availability, scalability and other architectural quality requirements?
• Solution architect: How are the technologies and information weaved together from all architecture domains to form a complete solution that allows a prospect to apply for an auto insurance policy online?
• Software architect: How are the technologies, tools, frameworks and patterns used to construct a custom-built software solution that allows customers to self-service their auto insurance policy?

Clearly, effectiveness as a software architect demands mastery that stretches across several areas. Spanning four categories, following figure illustrates the skills of the modern software architect. You can also read more details on sfia.

The Trends: More Precision, Autonomy and Disposability

Precision is exactness, accuracy and total control. For architects, precision is our ability to serve the software feature and functionality needs of a specific audience in a specific use case or scenario with total effectiveness and efficiency while taking full advantage of elasticity and available data. Taken to its logical extreme, this means that we can deliver solutions that serve ever-more-focused audiences, even down to an audience of one. Sound crazy? This concept of focused personalization lies at the heart of headless architecture. Modern mesh app and service architecture (MASA aka micro-frontend and micro-services) enables developers and architects to create solutions that serve the needs of specific and narrow audiences, despite depending on a smorgasbord of APIs and services under the hood.

Autonomy is independence or freedom of action. For architects, autonomy is embodied in our ability to deliver solutions that empower individuals to be more productive, to take more ownership of their work and to work more independently. Application professionals improve autonomy when we deliver solutions that automate repetitive tasks, expand the capabilities of our colleagues and customers, or enable them to delegate work to a machine or algorithm on a selective basis. Autonomy means we can make better decisions and take action using vast amounts of data that might be impossible for a person to interpret without software-based assistance, up to and including applications based on machine learning.

Disposability is architecting solutions for a changing world, a changing customer base and changing competitive and market conditions. The only certainty is that today’s pace of change will continue and even accelerate. Seasoned application professionals have lived through generations of once-cutting-edge technology that gradually became deprecated, ossified legacy systems. Gold-plating a solution as permanent is an exercise in futility. To future-proof your career, get better at architecting and supporting solutions that quickly recover from the inevitable failures that happen all the time in the cloud. Find cheaper ways to fail faster by taking on a greater number of smaller projects and changes that deliver incremental value over time. And, of course, adapt your skills quickly and continually so that you do not become disposable yourself.

Digital business will continue to be a strategic driver: Digital business transforms industries through the digital integration of people, things and businesses. This digital integration represents a massive scope of investment in new kinds of infrastructure, and its execution will change fundamental business assumptions. For example, deep customer understanding will continue to gain importance because it is the key to successful digital business initiatives. Thus, this understanding will also be critical to the career development for architects and other key engineering professionals.

Successfully building a digital business technology strategy will hinge on an enterprise’s ability to integrate systems in a way that allows for maximum flexibility to support shifting business demands. Digital transformation takes this even further by putting technology at the heart of business operations and innovations. To support the transformation to digital business, your organization will need to deliver and support the appropriate technology platform. This is not a discrete product or stack, but the applications and services that provide a platform for the business to operate, grow and adapt.

Planning and designing decoupled data (micro-db) is challenging for teams accustomed to building applications that rely on a single underlying database with a relational model that enforces consistency and referential integrity.

Data consistency and relationships must now be managed in service and interface design. To address data complexity, you must define how this data will be used in two contexts:

• Operational — What dependencies does each service have on data owned by other services?
• Analytical — What are the needs for aggregate use of data owned by your services, such as business intelligence (BI), reporting and auditing of data?

Decoupling inner and outer architecture decisions is an important planning consideration because it enables the implementation of discrete application workloads, services and microservices to be decoupled from the platforms to which they are deployed.

This will enable more flexibility in choices of both the frameworks and runtimes used for individual services, as shown in above figure. In addition, it will also help make changes in the outer architecture more manageable. As capabilities are updated or replaced, their impact on existing services should be minimized. We refer to the set of capabilities that support the loose coupling of services as the “service mesh” — this provides capabilities such as service discovery, request routing and access policy enforcement. It may also enable improved communications resilience (such as through circuit breakers and retry policy) and improved collection of telemetry data.

Build Business Acumen

Gaining knowledge and experience in important business domains will pay dividends in pursuing promising application career directions. Architects say they are challenged to fill the business knowledge/acumen talent gap in their organizations. The ability to knowledgeably and persuasively relate applications to specific business goals and challenges is a rare commodity among people who also possess high-value technical skills. The more you can excel in both areas, the more valuable you’ll be. Two key steps needed to bolster business-related competencies are to identify high-value business domains, and then take concrete steps to develop expertise in those areas. Take a structured approach to building your business acumen, as shown in below.

The “soft skills” that help any professional excel — such as communication, creative problem solving, project management and versatility — are particularly important for architects, and should not be overlooked as part of your career development efforts. Three key steps in this area include:

1. Invest in overcoming common skills and competency gaps.
2. Research and practice design thinking.
3. Become a “versatilist” architect as shown below

Communities of practice are stable, informal and voluntary groups organized around knowledge. The people in these groups share a concern or a passion for something they do, and learn how to do it better as they interact regularly. Practitioner-led communities are fundamental to open, collaborative and effective learning. Each community is “owned” by the people actively working in the relevant subject areas, who use it to address the problems they identify as most pressing. The people involved should be passionate about the community’s topic, and should also be intrinsically motivated to participate (see below). Intrinsic motivation is an individual’s internal enthusiasm, ambition and interest in the work itself — their personal drive to contribute to something they care about.

Invest in the Right Technical Skills

• Enterprise Agile and DevSecOps, PlatformOps, IaC, etc
• Application Security
• Multicloud and Hybrid Cloud
• Event-Driven Architecture
• Conversational Computing
• Microfrontends, Microservices and APIs
• Total Customer Experience Apps on omni-channels
• Digital Commerce
• Hybrid Integration Platforms
• Headless Enterprise Applications
• Containerization
• SaaS Customization

Build Interpersonal Skills and Relationships

The best tool for career growth can be found in building meaningful interpersonal relationships. This is one more reason that developing soft skills related to communication, collaboration, persuasion and leadership will pay dividends for your professional development. You can build these skills by taking initiatives, such as volunteering to deliver presentations, speak at review meetings and moderate discussions.

Building relationships with business colleagues is key. Learn to recognize business value and to develop empathy for users by interacting with business peers and investing in user-experience skills. Go to lunch with peers who are not part of your normal development circles. Find out what they do, and what their problems are. Helping people solve their business problems is a great way to advance your career prospects, while also building your collaborative competencies.

Integration Architecture Skills

Integration is changing. Enterprises are creating new solutions using technologies such as distributed cloud-native applications, microservices and new data analytics platforms. You are expected to connect these systems with each other, and with your existing applications and data, to create real-time processes and data flows. These technology trends also increase the types of endpoint you need to connect to and the way you go about integrating them. As a result, the skills you need to design integrations are also changing — for example, the Internet of Things (IoT) requires that you develop skills in streaming and event-based integration. You must implement a technical API strategy that allows you to deliver more integrations faster. You will be called on to use integration skills to automate business processes for digital transformation and to deliver data from IoT devices and to machine learning (ML) platforms. To meet these integration challenges, you must learn new skills.

APIs are more than just a technical capability that enables applications to connect. They are the programmatically consumable embodiment of a business capability, opening new opportunities to create value for customers, partners and employees.

Integration architects have a role in designing and creating modern API endpoints that sit in front of legacy systems (for example, putting a modern REST API in front of a legacy ERP system). This approach allows ad hoc integrators (usually software developers who need to deliver an integration flow for a particular requirement) to integrate with the legacy systems. They do this by using platforms with a simpler developer experience, such as integration platform as a service (iPaaS) or dual in-line package (DIP).

This democratized approach embodies the “dumb pipes, smart endpoints” approach, with specialist integrators creating the smart endpoints for legacy systems and enabling ad hoc integrators to wire together dumb pipes (see below).

Architects defining APIs will need a good understanding of the tools used to create formal API specifications, such as OpenAPI (formerly known as Swagger) or RAML (RESTful API Modeling Language). They will also need to master the approaches used in API-first design, such as mental modeling and scenario definition. These skills are evolutions of existing architectural skills used in interface and service design, so they will be easy to learn, easy to apply and a significant benefit.

API management is the set of skills and technologies that allow APIs to be delivered and governed as products with their own life cycle, rather than as just technical interfaces.

You will need to develop the following skills:

• Architecting and delivering an API management platform
• Defining API security and access control policies
• Packaging APIs together into products
• Managing API products and their life cycle

An API management platform consists of several components:

• An administration service, where you create policies and manage your API catalog
• A developer portal that provides documentation and developer enablement features such as test harnesses
• One or more API gateways that act as policy-enforcing proxies

Creating the platform used for API management usually falls under the remit of an integration architect. This involves not only selecting a product (or products), but also architecting how the platform is used, including making decisions, such as:

• How many environments do you need?
• Will you use microgateways, enterprise gateways or both?
• Will you use the same API management platform for internal and external APIs?
• Who has access to deploy and manage API definitions and documentation?
• Will you expose external SaaS services in your API gateway for internal consumption?
• How will you group APIs for deployment and management?

Agile software development approaches have completely transformed how organizations deliver software. Agile development focuses on working collaboratively with the customer, delivering regular releases and using feedback from these to refine the product.

Develop the following skills:

• Delivering using agile methodologies
• Architecting self-service integration platforms
• Working as an integration architect in agile teams

One of the main goals of agile is to prevent an issue seen with waterfall approaches — by the time you deliver the software it is out-of-date. Agile development has self-contained teams with minimal dependencies that deliver frequent releases — a model that does not fit well with the traditional approach to integration, where a central integration team creates integrations on a shared platform.

Agile software development requires an agile approach to integration.

To do proper secure integration architecture, you will need the following skills:

• Defining and applying security for the consumption of APIs
• Securing data in-flight and at rest using appropriate data protection techniques, such as encryption, tokenizing and masking
• Controlling access to configure, monitor and deploy to integration platforms for a variety of roles, such as administrators, developers and trusted business partners

You should evaluate your business-critical integrations with the same level of scrutiny and rigor that you exercise over the applications they integrate with.

To do this:

• Define how you will protect your integration flows from the four main categories of attack on APIs and integration points: exploits, abuse of functionality, access violations and denial of service (DoS).
• Implement granular security to lock down both authorization and access to the lowest level of functionality or data possible for an integration flow.
• Ensure that sensitive data is encrypted in transit using Transport Layer Security (TLS) 1.2 or newer to safeguard communications between endpoints.
• Ensure that sensitive data is protected at rest using native mechanisms in the platform or supplementary third-party tools to encrypt, tokenize or mask sensitive data types as appropriate or as mandated by compliance or regulation.
• Deploy and use runtime protection technologies such as web application firewalls (WAFs), cloud application security brokers (CASBs) and API gateways to reduce the attack surface of your integrations and to inspect traffic for threats.

Event-driven architecture is an architectural style where communication between components or services occurs via the emitting and consuming of events, rather than by requests and responses. When something happens in Service A, it generates an event. Another service (Service B) consumes that event, performing additional processing. EDA is particularly interesting for integration architects because it offers a powerful, scalable and robust way to connect systems with minimal coupling while still providing governance and oversight.

You will need to develop the following skills when applying event-driven architecture:

• Transitioning between synchronous and event-driven message exchange patterns
• Managing eventual consistency and using sagas
• Using choreography to compose processes and applications from events
• Storing and managing data using event sourcing

You must learn when, where and how to apply these protocols. Some protocols are not new but are seeing a surge in popularity, such as Advanced Message Queuing Protocol (AMQP). Others are new and are still evolving, such as gRPC. Prioritize learning protocols that are relevant to initiatives your enterprise is adopting or evaluating.

Streaming architectures, including event streams and data streams, are becoming more popular, driven by IoT (where sensors supply streams of events), data lakes and microservices architectures. The stream processing pattern bears many similarities to the message processing pattern that you are familiar with, but in stream processing, the processor looks at one or more streams as a whole, rather than at discrete messages. Streams are aggregated, combined and filtered to observe patterns and enrich data. The output of a stream processor is itself a stream, which may consist of filtered or mapped data or events.

There are several skills that you will need for stream processing architectures:

• Performing mediation operations on streams, such as combining or splitting them, or transforming the events or data within them — for example, converting streams from two different types of IoT temperature sensors into a single stream
• Creating streams from nonstreaming platforms, such as creating a stream of data change events from a database
• Adding streaming capabilities to your hybrid integration platform to allow streams of data and events to get from their source to their destination — for example, adding Apache Kafka Streams

You need a deep knowledge of the skills that you use day-to-day in your job, but for other skills, you need just enough knowledge to get started — and to know where to look to learn more when you need to. A T-shaped architect supplements the deep knowledge of his or her core skills (the vertical bar) with a wide set of skills that have shallower knowledge (the horizontal bar of the T). See below.

• Start with the core skills. The skills labeled as “core” in this initiative analysis are the foundations for how you create integrations. First, make sure you already have a good understanding of the existing core skills (see Note 1). Then, learn API design, API management, agile integration and information as a second language. These approaches are transforming how integration is performed and will be key to your success in the next two years.
• Prioritize skills that relate to initiatives within your enterprise. You should not wait until you need a skill to start learning it, but you will find skills much more valuable when you have a chance to apply them. By choosing skills that relate to initiatives your enterprise is engaged in (such as cloud, IoT or machine learning), you will find the learning more rewarding.
• Always be learning. Look for opportunities in your day-to-day work to learn new skills by investigating whether they can provide new ways to solve today’s problems. It is much harder to catch up with the skills you will need for modern architecture if you fall behind than it is to keep on top of them, learning a bit each day. Learning does not have to occur through formal training courses or time set aside to follow a tutorial. When you are defining your approach to a particular problem or task, spend a few minutes identifying and investigating alternative options, even if you have a suitable approach in mind. Knowing that other options exist, and the basics of applying them, may provide a better approach or allow you to more accurately defend the approach you select.
• Use video tutorials to accelerate learning. The hardest part of learning is getting started, especially if you need to install and configure software or a platform before you can begin. Video tutorials provide a way of temporarily postponing this hurdle by allowing you to watch someone else performing and explaining the skill. This enables you to quickly judge whether the skill is worth learning in more detail, and it gives you an overview of the tools and techniques involved.
• Create communities of practice to share knowledge. Learning with others allows you to not only collaborate and learn faster by building on each other’s knowledge, but also test your understanding of a topic by explaining it to others. Use topic-based knowledge communities to collaborate on learning opportunities.

Learn skills that enable you to architect platforms that empower others to be self-sufficient.

Cloud Architecture

Many successful organizations develop a “cloud-first” strategy. In order to successfully deliver on this strategy, the cloud architect will need to be an internal champion and leader for the cloud initiative. Cloud first means cloud is the first and preferred option for new IT investments. Cloud first does not mean “cloud everything.”

Foundational Architecture Approach for Building Public Cloud IaaS and PaaS Environments:

In this framework, there are 10 distinct functional technical disciplines that organizations should review, plus security considerations, that should be reviewed prior to moving applications to the public cloud environment en masse.

• Master Accounts and Billing: A hierarchical structure for accounts is needed for a variety of reasons. These range from resource isolation, cost management, security practices and alignment with organizational structure. (Foundation Item №1: Master Accounts and Billing)
• User Identity and Role-Based Access Control: Establishing an identity and access management strategy early in the cloud adoption process is critical for preventing security and availability issues. Doing so upfront is considerably easier than retrofitting security policies into a platform later. (Foundation Item №2: User Identity and Role-Based Access Control)
• Core IP Transit and Name Resolution: Establishing a hybrid WAN strategy that prioritizes good connectivity between offices and cloud providers is critical to enabling services for users. Determining how name resolution takes place within on-premises infrastructure and cloud providers will be a part of addressing WAN connectivity. (Foundation Item №3: Core IP Transit and Name Resolution)
• Storage: Storage of different flavors is consumed by all manner of cloud services. Planning storage consumption around availability, performance, resiliency and price will be important for ensuring long-term success and efficiency. (Foundation Item №4: Storage)
• Application-Specific Networking: Networking with a cloud provider utilizes different technologies and presents new challenges for organizations. A sound networking strategy for applications, especially production applications, is necessary. (Foundation Item №5: Application-Specific Networking)
• Compute: Establishing the amount of compute usage and the method by which it is purchased will need to be discussed and operationalized. Establishing highly resilient applications on compute requires further understanding of the cloud provider’s availability technologies. (Foundation Item №6: Compute)
• PaaS Services: Organizations often have a preference for PaaS services when adopting cloud services. Determining how certain application components can be replaced with PaaS services can enable greater ROI than simply lifting-and-shifting existing components (Foundation Item №7: PaaS Services)
• IT Operations Management: After establishing the strategies for compute, storage, networking and PaaS services, all IT operations processes should be reviewed. The organization should determine which procedures, if any, will still work with the applications that move to the cloud provider. (Foundation Item №8: IT Operations Management)
• Continuity and Availability: Building resiliency and disaster recovery (DR) procedures into the application design enables the organization to respond to a service impact. This is especially true for production applications. (Foundation Item №9: Continuity and Availability)
• Governance: After building the framework for reliable applications in the cloud provider, building effective governance will ensure compliance with financial, security and other policies at scale. As cloud usage grows, this will require the cloud team to review policies with a wider group of business lines and groups. (Foundation Item №10: Governance)
• Security: At minimum, workloads and data in the cloud will need to be secured to an equivalent level as on-premises, if not more. Fully utilizing the native security controls within cloud services, instead of forklifting on-premises security technologies, is needed. (Foundation Item №11: Security)

Another core task for the cloud architect is to develop and coordinate cloud architecture across a variety of disparate areas within the organization. These areas include (but are not limited to):

• Application development
• Application portfolio and life cycle management
• Data management, analytics and protection
• Enterprise management
• External IT hosting
• Governance
• Identity and access management (IAM)
• Infrastructure
• Integration
• Network
• Security, privacy and compliance
• User experience

The lead cloud architect cannot forcefully change IT or business culture within your organization. But, the cloud architect can influence the change in behavior toward the adoption and consumption of cloud services, and this changed behavior will lead to a culture of embracing cloud services as the primary, prioritized and promoted approach.

For example, a cloud architect should influence new usage patterns by developers to instrument their consumption of cloud services only when necessary rather than keeping services running 24/7. Similarly, a cloud architect should influence colleagues in procurement to deal with cloud contracts in different ways than more traditional hardware or software contracts.

Figure below is not meant to serve as a definitive organization chart model, but rather an example that organizations can use to fit the positioning of the cloud architect into their specific models. No indicator of success dictates to whom the cloud architect should report, but successful organizations ensure that a cloud architect reports to a person of influence, such as a chief enterprise architect, a senior IT leader or a manager of architecture.