What is an enterprise architect and what do they do?

Way back when mainframe was the only solution for enterprise computing, there was one system next to warehouses of paper forms, and it was the architecture and interoperability of the mainframe code with itself and a small set of other systems that was important.

Fast forward to today, and virtualization overtook physical servers and cloud and infrastructure-as-code overtook virtualization. Columnar in-memory databases complimented relational and graph databases; C over took COBOL and Java overtook C; big data and data-lakes overtook data warehouses; noSQL and Python complimented classic SQL. Innovative technology that was meant to be harmonized and integrated instead just exacerbated complexity and slowed innovation in the overall technology landscape.

Without optimizing the technology landscape for speed and agility, shifting consumer expectations for seamless connected experiences will increase complexity, expense, and slow delivery. Coupled with continued growth in the regulations (such as GDPR or AML) that businesses must comply with — it’s obvious that there is a need for simplification.

To solve this problem the enterprise architecture needs to be organized into layers, and layer the older with the newer, to ensure these layers can easily couple, decouple, co-exist, and co-operate using standardized interfaces like MuleSoft’s lightweight APIs. Optimizing the right parts of the tech estate at the right time to meet the fiscal and business objectives, making it work together as a functioning whole is the enterprise architect’s contribution to ongoing business success.

This layering approach is necessary because it is more cost-effective, and is faster and easier than rebuilding these systems from scratch, while the business and customers rely on them for day-to-day operations.

The business benefit of the enterprise architect role is to navigate the big challenges of IT change in complex operating and trading environments.

In its simplest definition, an enterprise architect is the business and technology “architect” of an organization’s or businesses technology estate, who is responsible for the upkeep and maintenance of those technology systems.

Typical principles that an architect will follow involve a mixture of software engineering best practices with business acumen and refactoring thinking to achieve fundamental business outcomes. The core purpose of the job is to “balance concerns.” This means, finding the correct balance between business outcomes, elegance, cost, technical advancement, future agility, and avoidance of technical debt is achieved.

Some of the responsibilities they have within an organization are to ensure:

• Business and technology leaders have bought into an architectural approach for digital and technology change.
• Interoperability standards and protocols are observed.
• The annual tech budget is aligned with the approved architecture strategy and roadmaps.
• Forward architecture qualities (like: agility, robustness, elasticity, scalability) are improved with any spend.
• An architecture governance council is established and effective.
• Enterprise patterns are developed and used.
• Digital-first, digital-by-design, cloud-first is implemented.

A major focus for an enterprise architect is IT cost savings and reducing technical debt for the organization. They are looking to scale the enterprises’ existing and new capabilities quickly, while meeting a diverse and disparate set of business and technology stakeholder needs, and not burdening the organization with future complexity.

A typical enterprise architect, broadly speaking, spends their time on the following tasks:

• Developing strategies, principles, and roadmaps in alignment with business strategies and objectives.
• Budgetary, project, and program governance to those strategies, principles, and roadmaps.
• Innovation, future product, and tech selection.

One of the key tools for governance is to define and evangelize guiding principles to shape the kinds of cloud, application, data, platform, and security solutions that deliver the enterprise architecture in total.

One of those we have already mentioned digital-by-design, but other examples include:

• Data is an enterprise asset. Whether at rest or in motion, important data (not all data) must have a common business and technical definition, a well-defined and standardized interface realized by an API specification. As well as appropriate data quality and compliance processes monitored by data stewards and data owners.
• Applications are regularly updated. All business critical applications will not be out-of-date by more than two major versions and must always be updated with regulatory and legal patching. If any critical applications are more than two versions out-of-date the priority for investment is to remediate over innovate.
• All systems must be mobile accessible. All web apps — both internal and external — will be capable of running on iOS and Android. Any web apps that cannot run on both iOS and Android must be migrated to the authorized digital-first cloud platform(s).

Typically these are SMART goals , accompanied by an owner, scope, context, rationale, implications (like: untangling legacy system integrations that slow innovation) and timeframe.

Using these principles and other negotiation tools helps clarify why one set of decisions and roadmap steps is favored over others. When business needs change, these principles must also change. Exemption for any project or program from compliance with these principles must be sought at the architecture council and ratified by the CIO or CTO or both. This makes decision making consistent over the long term, but is subject to political and commercial judgements.

With the complexity of many enterprise’s systems growing exponentially, a key topic over the last two decades is system integration. The challenge many organizations run into is how to connect all of these systems up to make a logical functioning whole. Integration over the years has gone from slow overnight batches of data to real-time queued parcels of messages, but unfortunately the problem hasn’t gone away.

One reason for this is the speed of development. Services based on the XML/SOAP protocols became unwieldy and “monolithic” — something a great enterprise architecture avoids. It also requires specialist and expensive knowledge that took ten years to master.

The other reason this “correct in theory” approach didn’t work is that it was invented in a pre-cloud time. Integrating everything neatly and transparently on-premise is one thing, integrating between on-premise to cloud, or cloud to cloud, monitoring the network of integrations (the application network) that are needed to support immersive and connected customer experiences is a large undertaking. Architectures that use complex and arcane standards and opaque technology for integration that mimic point-to-point interfaces is slow and expensive.

That’s why MuleSoft uses lightweight fast APIs to power digital transformation, making it a great companion for realizing a successful and adaptable enterprise architecture. It hits all the topics to create an agile composable organization that can pivot quickly to future unforeseen needs.

It does this by breaking down data and process silos, making data and process simple to power connected experiences and further new business opportunities and new markets, while making your digital transformations efforts cheaper and faster.

Learn how to build an architecture that is composable — allowing you to add new technologies with ease by downloading our whitepaper.