Understanding the Implicit Requirements of Software Architecture

I was reading an article today on the MSDN Architecture website titled Are We Engineers or Craftspeople? I found the following point very interesting:

Implicit requirements are those that engineers automatically include as a matter of professional duty. Most of these are requirements the engineer knows more about than their sponsor. For instance, the original Tacoma Narrows Bridge showed that winds are a problem for suspension bridges. The average politician is not expected to know about this, however. Civil engineers would never allow themselves to be in a position to say, after a new bridge has collapsed, “We knew wind would be a problem, but you didn’t ask us to deal with it in your requirements.”

This is a great analogy to implicit requirements within software architecture, and I believe that this idea separates the experienced senior software developers and software architects within the industry. 

In determining the architecture of a software system, it is the “duty” of the software architect to determine potential problems or risks with a design and mitigate or eliminate these risks.  The stakeholders of the project, don’t necessarily understand these risks nor do they necessarily understand their importance to the long term success of the project.

Let me describe four risks in software architecture and development that a Software Architect needs to implicitly understand and realize about the system they are designing.  When it comes to these potential risks, getting it right the first time should be a top priority in the architecture of the system.

Scaling

Recognizing the scalability requirements of an application are very important.  It is important to understand what the projected future usage, user growth, and data growth will be in the future.  A good rule of thumb is to then multiply this by a factor of 2 or 3 and develop the system based on that projected future growth.  It is important that your development environment be continually tested against this high usage and ensure that your development methods, strategy, tools, environment, and connected systems will effectively scale as well.

Also, regardless of the future requirements to scale, experience will demonstrate the type of development or tools to use that will scale well that do not necessarily have an impact on the development time or effort required.  These are approaches that should always be used, and they are a testament to the skill and experience of the developer or the individual leading the developers, such as the Software Architect.  An example of this would be in developing your database views or queries:  It is known, based on experience that there are good ways to develop these queries that will give the best performance out of the box versus other designs that may give the same results, but are slower, inefficient, and don’t scale well. 

By overlooking the importance of scalability, there is the potential for complete system breakdown when the usage of the system exceeds its capacity.  This will leave developers scrambling to spend additional time to fix the core scaling problems of the system, or force a potentially expensive purchase of beefier hardware (that otherwise should not be required) to support a badly scaling system.

Incompatibility

It is necessary to identify any points of incompatibility with the software system.  You have to look at all of the interfaces and interactions of the software system, human and systems,  currently and in the future.  This ranges from the users using the system to the other software and hardware components that interact with the system in a direct or indirect way.  It also includes future compatibility because it’s important to look at future requirements and ensure that the system is developed to meet those requirements.  To do this effectively, the Software Architect needs to have a broad understanding of a wide range of technology in order to make the right choices and also the business processes around the software system.  In essence, based on experience and skill, the Software Architect will pick the correct technology to support the current and future system compatibility of the application.

Failing to effectively perform this step could result in overlooking a critical system connection and cause additional development, resources, and funding to correct.  A system could leave some users in the dark and unable to access or use the system if they are using older or unsupported systems.  A good architecture would have accounted for this from the beginning to ensure all users (legacy and current) can use the system.  Another example could be a web application or intranet site that doesn’t work properly with a newer browser such as Internet Explorer 8.  Now, additional time and money would need to be spent in order to get it up to a standard that will work across multiple web browsers.  This could also impede a company wide initiative to upgrade all web browsers to Internet Explorer 8.

Future Maintenance and Enhancements

The future maintenance of a software system is incredibly important.   This idea should be instilled in your brain from the beginning of the software project.  Future maintenance and enhancements encompass everything that will make future updates, bug fixes, and new functionality easier.  A solid framework for your application is important, along with development/coding consistency, standards,  design patterns, reusability, modularity, and documentation.  It is important to understand these concepts, in order to fully benefit and utilize them to their full extent.  An experienced Senior Developer or Software Architect should have a full understanding of these concepts, why they are important, and how to implement them effectively. 

Overlooking this key factor could leave you with a working application, but code updates, fixes, enhancements, testing, and the learning curve required for new project members will be greatly diminished.

This step is sometimes what I call a “silent killer”, missing this step or lacking experience in this area may not be apparent to the end users or stakeholders of the software system at first, but it will have a huge drain on the ability to use, leverage, and maintain the application.

Some serious disadvantages I’ve seen first hand with this type of system are that users will report critical bugs that are difficult for the developers to track down and fix and developers become “mentally drained” and discouraged from doing any kind of maintenance or enhancements to the system.  Because of this and the fact that it will take many times longer to add new functionality to a poorly maintainable application, these types of systems evolve poorly and in a lot of cases end up being completely replaced by another system.  Think about the potential for unfortunate long term financial and business consequences when this step is overlooked! 

Usability

The software has to be useable.  You need to determine which functions are most common to the user and ensure they are easy to find and are the most prevalent features within the application.  Looking at a way to allow the user to customize the application goes a long way in order for individual users to customize the user interface so they get the most bang for their buck. 

The user interface, the technology behind the user interface (is it web? windows? java? or a combination of these technologies?), user customization, colors, contrast, and user functionality are important.  I also believe that a user interface has to look somewhat attractiveThe application itself should be useable and self describing without requiring the user to read a manual or documentation.  You’ll find that you will have more enthusiastic users and less technical or service desk support calls when the application is easy to use and performs the functions that the user needs to perform.  It should make the job of the user easier!  Simple things in your application such as toolbars, context sensitive menus, tabbed navigation, and even copy/paste functionality should not be overlooked.  User interface standards also need to be followed, as you do not want the user to be confused if the basic operation of the application differs substantially from the applications that they are used to. 

Basically, if users or customers do not want to use the software or application because it is too difficult or cumbersome, you end up with the users not actually using it and going back to the old way of doing things, or being forced by “the powers that be” to use it against their own objections about its usability.  Neither of these situations are ideal and they result in lost productivity or the inability to have future potential productivity gains come to fruition.

 

Conclusion

A failure to identify and mitigate or eliminate these issues could mean a failure or breakdown of the system.  This costs large amounts of money and time to do an “after the fact” correction that’s required, or in a worse case – completely wasted money on a failed implementation that ended up getting axed all together.  I’ve witnessed first hand accounts of both of these scenarios and they are not pleasurable for anyone involved.  As part of eliminating wasteful time and money we need to make sure that we do software right; gaining the right experience, skill, and paying attention to and understanding the implicit requirements expected of a Software Architect, we’ll have high functioning software that will serve its current and future requirements well, and provide a continual and exceptional value and return on investment.

In addition to the points above and though not touched on in this posting, I haven’t forgotten about Buy-In, Security, Availability, Having Proper Business Processes In Place, The Role of The Business Analyst, Communication, Team Leadership, etc.  These points are also very important in order to have a solid foundation for a software project.  I’ll definitely talk about these items in a future blog posting.

Thanks for reading!  I welcome any comments (positive or constructive).

Dan

Advertisements

About dandouglas
Dan Douglas is based in Toronto, Ontario, Canada and is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture. His professional experience represents over 15 years of architecting and developing highly successful large scale solutions. Dan also believes that properly empowering teams with trust and responsibility yields the greatest results. | For inquiries about Dan's software consulting practice, please see the contact page.  Dan has also built up a network of highly successful and professional Software Developers and Architects who are highly respected and can be called upon and used in conjunction with his own consulting practice to handle the largest of consulting projects.

3 Responses to Understanding the Implicit Requirements of Software Architecture

  1. Pingback: Software Engineering and Algorithms « Web Development

  2. Pingback: Algorithms in IT | Research, Dev and Share

  3. Pingback: Implicit requirements | simonsaysnomore

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s