Published on , in #engineering-strategy
One of the hard things in building software, I realized, are decisions: Which tech debt to tackle? How to architect this feature? What to focus on?
If you don't know where you are going, any road can take you there.
— Lewis Carroll, from Alice in Wonderland
What helps me to navigate the maze is an architectural vision. An architectural vision maps out what the applications should look like in the future from the architectural perspective. The vision should be reachable and reasonably challenging. For me, I'm excited when the vision is on the edge of my comfort zone—something to stretch my abilities. I've found that thinking in terms of one or two years from now is a reasonable timeframe: long enough to unlock substantial changes, short enough to be hands-on.
How does an architectural vision look like? Stripped to bare essence, it could be as short as a sentence. For example, a company has a CRM system causing them only headaches. They discover that customer relationship management is, in fact, their core. So their architectural vision could be: The CRM is built in-house.
Another example: a company operates in two different lines of business. The IT architecture supports both lines. Because of the shared foundations, the team faces mounds of complexity and overhead. So the architectural vision could read: IT systems are split into two separate buckets: systems serving retail customers and systems serving the infrastructure customers.
For me, such vision is a celestial compass, showing the path in everyday decisions. And with such a compass, the days feel different.
- ← Previous post: The spirit of kaizen
- → Next post: Embarrassingly simple proof of concepts
This blog is written by Marcel Krcah, an independent consultant for product-oriented software engineering. If you like what you read, sign up for my newsletter