A week or so ago, I ran a survey of the students in my architecture courses, asking them what their biggest challenges were.
In this post, we’ll look at the top 5 answers, from real working architects and senior application developers like you:
1. Dealing with Legacy Systems
Without a doubt, as we get into the 40th year of having enterprise-level software systems, we’re all feeling a bit burdened by some of these pain-in-the-neck (and difficult to replace) systems.
In fact, as I look back on the last 10 years of my career, I can’t really think of a project that wasn’t something like these:
- a system where the original developer is gone, and no one fully understands the system
- a system where, for whatever reason, no one wanted to have to touch if at all possible
- a system that has been “planning to be replaced” for several years, with no concrete schedule as to when
- a system where the original vendor doesn’t even support it any more (or indeed talk about it on their website)
If I had a magic wand, and could update to the latest version, or replace it with something more modern instantly, for sure that magic wand would be used a lot. Unfortunately, company’s sometimes prioritize certain things very low on the list, and we have to deal with them.
2. Explaining the Value of Architecture to Non-Architects
Oh man. What is architecture? What IS it? What do architects DO?
This question has been haunting people in the architecture space for ages. I even made not one, but two videos about it. (Please check those out, and subscribe!)
The thing to remember is, every system has an architecture. Whether an architect was involved or not, one or more people made some decisions on systems design that add together to become the system architecture. But would you rather have something that is designed intentionally, or something that just comes together without forethought?
If I offered you a house, and said that I built it one room at a time without thinking about any of the other rooms, does that sound like a well-designed house? Then why can computer systems (and ultimately the businesses that run on top of them) be designed only one room at a time and expect the whole house to make sense?
(Why are there 3 bathrooms in the basement and none upstairs by the bedrooms? Because there was no architect.)
3. Dealing with Application and Data Security
In 2016, security is a huge issue that anyone in technology has to deal with. Not only is it smart business policy to protect your customers data from being exposed, but it’s actually the law in many places that this data has to be responsibly protected. As architects, we need to be on top of the standards for security and ensure that our designs have thought about that before code has been written or systems set up.
Easier said than done, of course.
But from the way customer data is kept, to the way our networks are hardened from attack, to the limitations we place on users from outside (including the website user itself which will minimize the effects of a web-facing break in) are more important than ever, and will never be something we can take for granted.
4. Dealing with integration with other systems
Legacy systems were a big headache, but even interacting with non-legacy systems can be complex. How do you package and send GBs of sensitive data from one server to another when the other system only accepts XML files in a specific file directory as input? Sometimes you end up with middle-tier “connector” systems that just move files around, and sometimes you need to use third-party solutions like Microsoft SQL Server Integration Services (SSIS) or Microsoft BizTalk to pass and manipulate data around.
The ideal solution is for two systems to be designed to talk to each other, or use some industry standard protocol (an Industry Architecture on the Enterprise Continuum!) so that related systems can just work to implement a standard instead of worrying about direct integration with so many varying systems. But those standards are often overly complex (due to the number of irrelevant-to-you scenarios they have to deal with) or don’t exist for your specific need.
5. Feeling locked in with a single vendor, such that parts of the architecture cannot be changed
We’ve all been there. Your company has been using “Tool X” for analytics and reporting so long that the code is everywhere. In every web page, of every website. Highly customized for button clicks, opt-ins, video plays, and all sorts of events. And implemented slightly differently in every site it’s been added to. When asked, you estimate 12 person-months to swap out the “Tool X” code and replace it with another solution to the same level of customization for pages and events.
Sometimes you’re stuck. The cost to replace something doesn’t give the business the necessary return on investment to spend that money. And so you go year after year, with a tool that no-one really likes, paying more for it than you probably should, because it’s tool difficult to replace.
There’s no easy solution to that, except to vow that the next time you’re asked to implement some custom third-party code in all your web pages, you devise a system that puts that code in one central location. You need to abstract that and centralize it, so that it’s easy to upgrade to the newest version or swap out to a new vendor.
Those were the top 5 issues identified by my students. Anything that I missed?
[activecampaign form=7]
