keller - Fotolia
Address goals with various enterprise architecture strategies
Enterprise architects have a range of frameworks at their fingertips, but their role also entails creating consensus and understanding between business and technical stakeholders.
The concept of enterprise architecture comes with several varying interpretations that can cause disputes rather than consensus in software development. Instead of arguing about definitions, it's better to ask what someone expects within their enterprise architecture strategy, and rely on frameworks and communication to come to a common understanding that will benefit everyone involved.
Not everyone can articulate a clear picture for enterprise architecture, and there are many correct definitions for the term. So when you come to this impasse, don't dig a hole. Pause, and reflect. Ask what the other person means, and use their words to shape the approach to enterprise architecture strategy.
Within the broad categories that an enterprise architecture can encompass, some have a heavy focus on business processes and others strictly focus on technological components. The term is formalized into frameworks, but also relates to tasks such as enforcing consistent terminology, and translating business goals into executable code.
Technical enterprise architecture descriptions
Programmers and other technical IT professionals regard enterprise architecture strategies in terms of the infrastructure, application and management components under their control.
High-level programmers use enterprise architecture to refer to the hardware and software components in a design. For a website, that might comprise a web server, database, the NoSQL database cache, the API endpoints and the content delivery network. IT people tend to think of the architecture in these terms -- operating systems and databases they need to keep running.
Enterprise architecture can also revolve around important application decisions, rather than a diagram of software stacks. In the context of software architecture, decisions include the programming language, platform, type of cloud services used, CI/CD systems involved in deployment, unit tests, the data-interchange format for the API, where the APIs are registered and related systems. For some programmers, the term architecture means a look at just the highest level of design: a set of domain objects that interrelate, such as customer, order and claim.
Another view of enterprise architecture in the technical realm revolves around quality attributes. These attributes must exist for the software to work, but are unlikely to fit in a specification document. Examples include reliability, capacity, scalability and security -- even things such as uptime, measuring and monitoring levels, rollback approach, delivery cadence, time to build and time to deploy. Quality elements are not functional requirements, per se, but are ways to determine acceptable operating conditions and necessary tradeoffs to get there. The conversation about the tradeoffs for software projects is often more important than the final decision. When enterprise architects and application teams think in terms of quality attributes, they can discover and address problems for software in advance of it going live. However, this approach can have negative consequences if architecture requirements added to a project do not trace back to any real business need.
Enterprise architectures in a business context
Some organizations distinguish their enterprise architecture from the technical architecture required to build and run applications. Enterprise architecture frameworks help codify the business and IT relationship. Enterprise architecture can also be called business architecture here.
An enterprise architect might describe their job as drawing boxes, if the organization follows the Zachman Framework. This enterprise architecture strategy presents an organization's core questions -- who, what, when, where, why and how -- across the top of a schema. Down the sides, it moves through the organization's hierarchy from the executive perspective to management, architecture, engineer, technician and lastly enterprise users. The organization can describe how it runs by filling in the boxes for each intersection of hierarchy and questions. Architects should search out differences of opinion in these answers, and fix them to help the organization run more smoothly. The framework aims to solve business problems, such as how to process claims or fulfill orders, with software.
It can also be a core part of the enterprise architect's job to build a business glossary that translates into software -- and vice versa. Most large organizations have special internal acronyms, and even some acronyms for which the actual words are lost to history. Companies also use confusing or complex phrases to describe vital business operations. Software teams must interpret these acronyms and terms to accurately design systems for the company's needs. For example, one company uses the term days per thousand to roughly mean the number of hospital days used per year per thousand insured people. This company's teams have reports that generate these numbers, and they use at least three different formulas to do so. Enterprise architects facing these issues must take the time to translate sometimes nebulous tech speak into consistent business rules within applications.
Large organizations with many moving parts and opportunities for misunderstandings might find a framework focused on consistency and relationships between various disparate parts of an overarching enterprise architecture helpful. The Unified Architecture Framework (UAF) and Unified Modeling Language (UML) are designed so that adherents can visualize technology and software flows. UAF is a complex but flexible enterprise architecture framework suitable for military and government software development as well as use in commercial businesses. It's implemented as a UML profile. In Zachman framework terms, the UAF and the UML only represent a tiny part of the architecture, but to a software organization, they can embody the bulk of work for architects. Popular in the 1990s, UAF and UML are less discussed today, and frequently dismissed by adherents of the Agile framework extreme programming.
Compromise on EA definition disputes
Enterprise architecture and technical architecture are related yet different, according to Grady Booch, co-creator of UML, who published a take on the terminology in the IEEE Software journal, volume 27, issue 2: "Whereas EA focuses on the architecture of a business that uses software-intensive systems, TA focuses on the architecture of the software-intensive systems that are used by a business to make its mission manifest."
In the field, expect some enterprise architects to talk about servers rather than business, while some technical architects use business terms frequently. The real question of the day is: Can we agree on the problem and get on with solving it? Once that is done, what you call it suddenly seems less important.
Business and technology conversations
When business stakeholders interact with IT and software teams, they want to know deadlines, budgets, optional cuts and what's on the docket. These are certainly important subjects to address, and companies employ portfolio and project managers as well as analysts to figure out answers. They may even use project tracking software. Still, there is more to translate than just the budget. As the book The Phoenix Project illustrates, it's possible for a software project to hit its go-live date, yet fail to meet the real customer need. Organizations always need a good translator who can explain the nuances between various roles.
The task for an enterprise architect is not much different from what a building architect does. She works to understand the customer vision, visualize it for the customer and present it in a way that the project manager and builder can understand and implement well.
Looking at these enterprise architecture strategies laid out with frameworks and other concepts, they all try to convey the things that matter to technical people in a way that business people can understand. Essentially, they bring together technology and business with clarity and defined goals.
