Skip to content
Tiatra, LLCTiatra, LLC
Tiatra, LLC
Information Technology Solutions for Washington, DC Government Agencies
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact
 
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact

6 deadly sins of enterprise architecture

Keeping the enterprise running has never been an easy task. The rise of software tools have made many parts of the workflow faster, smoother, and more consistent for everyone but those who have to keep the software running. It’s like the old line about a duck gliding along a pond: Everything above the water looks placid, while below the water line the feet frantically paddle.

To the casual end-user, manager, or C-suite exec, an enterprise architect’s job is magical. The endless chores of synchronization, organization, and stabilization all handled by computers so humans can do what they do best. But all the web portals, collaboration stacks, and repository omnitools hide the endless challenges of keeping everything straight. For all its advances, enterprise architecture remains a new world filled with tasks and responsibilities no one has completely figured out.

Enterprise architects are still learning, experimenting, and then learning more about what they should do and — more importantly — what they can’t do. Along the way many mistakes have been made and are likely to be made again and again as we search for the best way to keep the software stacks running and the working life of everyone throughout the organization as simple as possible. Some of this is due to the highly technical and complex nature of the job. But some of it is because of the following sins we enterprise architects keep committing.

Storing too much (or too little) data

Software developers are pack rats. If they can, they’ll cache everything, log every event and store backup copies of the enterprise’s endlessly evolving state. But all those gigabytes and petabytes add up. Even at the lowest costs of cold storage offered by some of the cloud vendors, the little charges can be significant when the data is big.

To make matters worse, finding the right bits gets harder as the data lakes get filled to the brim. Like that warehouse at the end of Raiders of the Lost Ark, technically all the information is there, but can you ever find it?

The problem is that keeping too little information comes with its own failure modes and pain points. Some companies have tried setting data retention policies to destroy everything as soon as regulations allow. But then the enterprise muddles along with a kind of amnesia as every answer to every question seems to be, “We don’t have that file.” No one knows anything.

Finding the right balance may be impossible. All we can do is try to find a good data storage architecture that files away the right information in an easily accessible structure so that it doesn’t seem like everyone is just fumbling around in the dark spending most of their time looking for a light switch.

Relying too much on one platform (or embracing too many)

The simplest way to build out enterprise software is to leverage the power of various tools, portals, and platforms constructed by outsiders. Often 90%+ of the work can be done by signing a purchase order and writing a bit of glue code.

But trusting the key parts of an enterprise to an outside company has plenty of risks. Maybe some private equity firm buys the outside firm, fires all the good workers, and then jacks up the price knowing you can’t escape. Suddenly instantiating all your eggs in one platform starts to fail badly. No one remembers the simplicity and consistency that came from a single interface from a single platform.

Spreading out and embracing multiple platforms, though, can be just as painful. The sales team may promise that the tools are designed to interoperate and speak industry standard protocols, but that gets you only halfway there. Each may store the data in an SQL database, but some use MySQL, others use PostgreSQL and others use Oracle.

There’s no simple answer. Too many platforms creates a Tower of Babel. Too few brings the risk of vendor lock-in and all the pain of opening that email with the renewal contract. And we haven’t even spoken about the cost of bringing all development in house.

Outsourcing too much (or too little) to the cloud

The cloud has made life much easier for enterprise architects. If someone needs a machine of a certain size, well, it can be available in minutes. No need to fill out purchase orders. No need to find rack space. No need to do anything but give the cloud company your credit card number.

The upsides of having any machine available in minutes or even seconds are obvious. The biggest downside is the price. Cloud computing is often dramatically more expensive than doing the work in-house. Many CFOs dread opening up the cloud bills each month because they’re often larger than anyone expected.

But doing the work yourself means managing — and paying for — a staff, a data center, and more. The list of headaches and regulations can be long and the joy that comes from a smaller budget can be fleeting.

Some enterprise architects can win big with the cloud. If your demand spikes for a small amount of time each week, month, or year, spinning up the servers needed to handle the load for just a few minutes or hours can be dramatically cheaper than doing anything in-house. Everyone else is left wondering whether they’ve invested too much or too little in the cloud.

Embracing (or ignoring) the cult of framework

Now the complexity of today’s enterprise stacks, some smart architects have created frameworks to help organize them. The Open Group Architecture Format (TOGAF), for instance, is a strategic framework for building practically everything an enterprise would need. It offers a number of guidelines and best practices including an architecture development method (ADM) and an architecture compliance framework (ACF), among other acronyms. Others approaches, such as the Zachman Framework or the Federal Enterprise Architecture Framework (FEAF), bring their own versions of rules and regulations for building out a stack.

The biggest advantage may be consistency. Once everyone in the organization becomes familiar with the techniques and theories, finding the way around the software becomes easier. The data and the code is (usually) structured so that everything is in a predictable place.

Some people take it too far, however. Instead of just adopting the rules, they join a cult. They read the specs with such thoroughness that every decision must be made following the rules. Woe be it to thee who strays from the path.

But even if everyone buys into the cult of the framework and the office planning meetings are filled with happy rule followers, other problems can creep in. Sometimes teams reject perfectly good open-source code simply because it doesn’t align with their desired architectural framework. Sometimes they refuse to work with vendors who offer good options that, alas, wasn’t developed with the right philosophy.

Adhering to methodology above all

Frameworks can give structure, but they can also give cover for sloppy, lazy, or even malicious behavior. Sometimes teams can drag out decisions because they’re waiting on someone to fill out the right TOGAF form. There’s a fine line between supportive rules and stultifying red tape.

One guy I worked with loved the Agile methodology and he managed to twist it enough so his team was anything but agile. He knew all the meeting rituals and was great at filling his “sprint” with lots of story points for refactoring code that was written just last week. His team never seemed to be moving very fast at rebuilding the credit card checkout method that he was supposed to deliver, but if you look at the graph of Agile points earned each sprint, his team had the greatest velocity in the office.

We need some kind of method for organizing the development workflow. Programmers can argue for days about whether something is agile this or waterfall that. If the project is bigger than one person can handle on a weekend, well, there needs to be some kind of strategy.

The problems come when you begin to believe more in the methodology than what your eyes can see. When that happens, clever coders can game the system and earn big prizes even if their code doesn’t do much of anything.

Following (or ignoring) the trends

Developers love to latch on to the latest ideas and models for enterprise architecture. Sometimes they’re lucky and the new trend actually fits their needs. Their application is a good example of what drove the trendsetter to come up with the idea in the first place.

But that’s often only partially the case. Use cases may bear resemblance to the application that inspired the trend but only after a bit of hand waving. In the meantime, dev teams are stuck frantically trying to make their code fit the trend. Sometimes huge blocks of perfectly adequate code are tossed away, just because they were written toward some formerly trendy goal.

The problem is that completely ignoring trends can be just as deadly. Sure, your code has stayed true to some original vision using databases, formats, coding standards, and protocols that work just fine, thank you. But if the entire world has gone chasing some trend, then so have all the vendors, tool makers, and potential new hires, too. At some point, trends and fads can become standards and sometimes something even worse: legal compliance requirements.

Enterprise architects can’t win. If they follow the trends, they’re slaves to fads of the mob. But if they ignore them, they can get left behind. All they can do is cautiously try to do the right thing for the organization’s tech stack and the IT pros who must tend to it.

Enterprise Architecture, IT Strategy, Software Development
Read More from This Article: 6 deadly sins of enterprise architecture
Source: News

Category: NewsSeptember 21, 2023
Tags: art

Post navigation

PreviousPrevious post:The year’s top 10 enterprise AI trends — so farNextNext post:CIOs worry about Gen AI – for all the right reasons

Related posts

SAS supercharges Viya platform with AI agents, copilots, and synthetic data tools
May 8, 2025
IBM aims to set industry standard for enterprise AI with ITBench SaaS launch
May 8, 2025
Consejos para abordar la deuda técnica
May 8, 2025
Training data: The key to successful AI models
May 8, 2025
Bankinter acelera la integración de la IA en sus operaciones
May 8, 2025
The gen AI at Siemens Mobility making IT more accessible
May 8, 2025
Recent Posts
  • SAS supercharges Viya platform with AI agents, copilots, and synthetic data tools
  • IBM aims to set industry standard for enterprise AI with ITBench SaaS launch
  • Consejos para abordar la deuda técnica
  • Training data: The key to successful AI models
  • Bankinter acelera la integración de la IA en sus operaciones
Recent Comments
    Archives
    • May 2025
    • April 2025
    • March 2025
    • February 2025
    • January 2025
    • December 2024
    • November 2024
    • October 2024
    • September 2024
    • August 2024
    • July 2024
    • June 2024
    • May 2024
    • April 2024
    • March 2024
    • February 2024
    • January 2024
    • December 2023
    • November 2023
    • October 2023
    • September 2023
    • August 2023
    • July 2023
    • June 2023
    • May 2023
    • April 2023
    • March 2023
    • February 2023
    • January 2023
    • December 2022
    • November 2022
    • October 2022
    • September 2022
    • August 2022
    • July 2022
    • June 2022
    • May 2022
    • April 2022
    • March 2022
    • February 2022
    • January 2022
    • December 2021
    • November 2021
    • October 2021
    • September 2021
    • August 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    Categories
    • News
    Meta
    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org
    Tiatra LLC.

    Tiatra, LLC, based in the Washington, DC metropolitan area, proudly serves federal government agencies, organizations that work with the government and other commercial businesses and organizations. Tiatra specializes in a broad range of information technology (IT) development and management services incorporating solid engineering, attention to client needs, and meeting or exceeding any security parameters required. Our small yet innovative company is structured with a full complement of the necessary technical experts, working with hands-on management, to provide a high level of service and competitive pricing for your systems and engineering requirements.

    Find us on:

    FacebookTwitterLinkedin

    Submitclear

    Tiatra, LLC
    Copyright 2016. All rights reserved.