No matter how pretty a face it has, your application system is only as good as its architecture – and that is driven by the business requirements.
So, you’re probably thinking “Why do I need to spend time on this when I hire people to handle it?”, but hang on:
Software architectural requirements are really all about the business – and working through the architectural requirements must be done early in any SDLC (that’s software development life cycle for you non-geeks).
Without a thorough understanding of what the business needs and where it’s going, the architecture may be flawed.
These software requirements are every bit as crucial to the structure of whether you build it or buy it — as the architectural requirements were for building your home. And just as you wouldn’t start building walls without a foundation in place for your house, the architectural requirements for your system should be defined before any coding takes place.
For any software development initiative – and for almost all purchased systems – defining the architectural requirements must be done early in the SDLC cycle: Before purchasing, before coding, before buying any software tools.
If architectural requirements aren’t well-defined, frequently serious issues arise – and at an architectural level, these issues, or flaws, are painful, costly, and worse.
Here are four starting points to help your organization start discussing needs for better defining system architectural requirements – and promoting better collaboration between business stakeholders and IT.
1. How critical is the system to your business – from geographic redundancies needed or is this a local office or department effort?
What is your uptime requirement? All systems don’t need to be up 7x24x365, meaning available every moment of every day.
The term 724365 or 7 by 24 by 365 means the system has to be up every day, 24 hours a day, every day of the year – that it can’t go down for maintenance or upgrades; that the system requires fault tolerance from multiple perspectives – geographic, network, infrastructure, database, etc.
If yours needs to be up at all times, the costs for the system will be considerably higher than a system that needs to be available during primarily business hours. Even if you’re selecting a system that’s being hosted – such as a “cloud” service or “SaaS” — this is a crucial topic. IF there’s a system outage, how long can it be down without impacting the business? How much data can be lost without damaging your business? A few minutes? A half day?
Don’t rush through discussions about the uptime requirements. Business stakeholders tend to assume that it’s not that big a deal to have a system up all the time. It is a big deal. Most systems can accommodate some downtime for maintenance windows. Talk through this with your business users.
2. What kinds of data will the system store – and are there legal requirements for that data storage or security?
How secure, specifically, does the system need to be – can anybody view part or all of the system (for example, public pages of a website)? Or is only part of the system open and users have to register and then undergo some confirmation process to gain entry? Or is a paid service? Or?… Next, how critical is the data that will be stored by the system? How secure does that data need to be? For example, are there legal requirements? Financial data? Personal health information?
3. What kinds of communications are needed with other systems, companies, websites?
What kinds of interfaces are required? For example, a credit card processing service or content management service? Next, will you be selling anything directly from the system? Will you need a “storefront”? And, never forget to get into discussions on what kind of reports might be needed – this can uncover serious needs.
4. What platforms should be supported for your (customers) users to be able to access the system: Who, where, how?
If the system will be available via intranet, extranet, or internet, what web browsers do you need to support – and “all” is usually not do-able for most firms. Should system be easily accessible and usable to smartphone users? So you’ll have a mobile version of the site?
These four topic areas are a sampling of the questions for the business stakeholders that will lead to clearly defining the software architecture.
There are many more to be considered, depending on the type of software system being designed or purchased. Some IT shops consider these architectural requirements — or NFRs (non-functional requirements) — more “technical requirements“; however, I consider those “technical requirements” to be IT-centric and really a part of system configuration management and development standards.
Architectural – or non-functional – requirements: Get them right the first time.
The business needs and vision are critical for internal – and ANY external – technology leaders to understand. Even, and especially, when you outsource, these requirements are vital to get clearly specified early and verified at the end of the requirements phase.
Finally, keep in mind that these types of “non-functional” requirements, as they’re generally called within the software community, are fundamental to a successful implementation – and a bad decision made regarding architecture can create a flaw that’s almost always painful and costly to fix later. Or worse.
By collaborating closely with the business stakeholders, IT can be better aligned and be assured of designing, architecting, and delivering a solution that will meet the business needs.