Being an Architect

Why Being an Architect, not Becoming an Architect?

The Goal of Architecture

  • 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.

BAUF is Flawed

  • 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

Principles for Increasing Architectural Agility

Prove It With Code

Architect All the Way Down

Generate Documentation

Validate and Enforce the Architecture

  • 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

Keep It as Simple as Possible

All Types of Architect Profiles

  • 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.
  • 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?

The Trends: More Precision, Autonomy and Disposability

  • 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?

Build Business Acumen

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

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

Integration Architecture 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 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
  • 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?
  • Delivering using agile methodologies
  • Architecting self-service integration platforms
  • Working as an integration architect in agile teams
  • 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
  • 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.
  • 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
  • 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
  • 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.

Cloud Architecture

  • 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)
  • 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



Scaling Up, Growth and Digital Transformation guy.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store