Posted by Michael Alfaro on February 16, 2011

10 (Additional) Things Every Software Architect Should Know: Learn Business from Data, Learn Data from Business

Inspired by O’Reilly’s 97 Things Every Software Architect Should Know, I am adding my own few things (10, to be specific, and not all at once).

The first one: Learn about the Business from the Data, Learn about the Data from the Business.

It’s all too common – you begin to work on a project, the client has a tight deadline and they need a new site/app/product launched, and lo-and-behold: you don’t know how the client’s business works! You have further conversations with them; they direct you to a different department or person (deflecting the responsibility, and possibly not doing their job). Before you know it, you’re herding cats, and trying to figure out how you got wrapped up in your current mess (and get work done at the same time).

In the middle of it all, you’ve lost track of what the client really wants.

One solution? Learn about the business from the data they provide, and learn about the data you need from the business itself.

Do they say they work one way, but in reality, most of their critical IT infrastructure is given a back-seat to front-office tasks? Do they say they want a cutting-edge new software tool, but lack the resources to manage and scale it? If you can gather as much data as possible, you will be able to see patterns and trends. How was the data delivered? How quickly did you receive access? Are there roadblocks and hurdles in accessing even the most trivial of data? From this you can determine the ‘change aptitude’ a client can (most likely) handle.

And what about the business? What are they successful in doing? Who are their strongest, and most dedicated, in-house resources? What departments drive the business? How do they currently analyze their data, make adjustments, and carry on? Is this a company that is rapidly growing, or are they bunkered into a niche market and afraid of changing? If the answers to the above are: ‘I don’t know’, then expect problems and push back on deadlines. While not every software project is the equivalent of climbing Mt. Everest, many contain traps, pitfalls, and landslides that can leave you with an unsuccessful result.

Some questions to ask:

1. How often are metrics analyzed and tweaked? How many people have access to the metrics, and how do they view Business Intelligence in making their decisions?

2. Is the client’s in-house development team agile? Do they welcome change requests and relish scaling to new heights, or will they balk when you recommend they update their blog that hasn’t been used in over a year?

3. What is their core competitive advantage? Is there a process or product they own that differentiates them from others?

Once you begin to understand both the data and the business itself, you can make educated decisions about the rest of the project: deadlines, software recommendations, features, etc.

Topics: architecture, business, technology