Being an Architect

Why Being an Architect, not Becoming an Architect?

The Goal of Architecture

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

  • 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

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

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.

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

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

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

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

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

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.



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