In this installment I’ll attempt to identify what I think are the primary concepts that all architects should have some familiarity with. There are, of course, countless topics in the field of software architecture, but I believe that these are the foundational concepts we should all become acquainted with ...
It should go without saying that I think you should have some familiarity with many of the prominent design patterns that have entered the vernacular. The most important of these include ...
In the end, our job is to solve some problem, typically a business problem. We must therefore have the ability to effectively elicit the users’ requirements for the software they want us to deliver.
There are many approaches to gathering user requirements. The most popular, as of this writing include ...
Architects should have the ability to identify the users’ tactical and strategic needs, and help them to prioritize their requirements as well.
This is possibly the most fundamental concept in systems design. Layers provide a way to structure and separate the functions of a system. For example, you are probably familiar with the following layers ...
Layers provide several benefits ...
The first three bullets in the list above help us to build systems that are easier to maintain and more flexible or adaptable towards the end of supporting changing business requirements.
The term layer and tier are oftentimes used synonymously, but it is more appropriate to use the term tier to indicate a separate physical deployment. For example, a simple web application might consist of two tiers, the web/application tier, and the database tier.
One should also be aware that as the number of layers in a software system increase, performance might suffer.
When you get down to it, there are three fundamental Object-Oriented concepts that all architects should be intimately familiar with ...
These concepts make up the foundation. On top of that, you might add such ideas as ...
If you want to be an architect and you’re not comfortable with these concepts, it’s time to get cracking!
This is a HUGE and ever changing area. Architects should have a broad awareness of the different modeling techniques available, and should be able to select the appropriate techniques for the project. Here are just a few techniques ...
I am one of those people who believe that architects must have a decent understanding of relational database design techniques. After all, the systems we work with typically read information from a relational database or write it back there. Yes, there are other types of data stores, but the RDBMS predominates. Additionally, the database is oftentimes the ultimate bottleneck because of its design.
The primary relational concepts that architects should understand include ...
You might also consider learning more about database design techniques that support Business Intelligence, Online-Analytical Processing (OLAP), and Data Warehouses; of course I'm talking about star and snowflake schemas.
It seems that everything goes in cycles. Several decades ago mainframes centralized all processing and data management functions. Then client-server came along and attempted to harness the processing power of desktop machines by distributing some functions away from a central location. Next came web applications and much logic was brought back to more centralized locations. Now we have the concept of Service Oriented Architectures, and well, here we go again with the distribution of data and logic.
When considering whether to centralize or distribute parts of the system, the architect must evaluate a number of factors. Here’s a partial list ...
Distributed systems tend to introduce performance issues, so beware!
This is another area that doesn’t remain static. I have observed, however, that while the names change frequently, the basic concepts remain the same.
One size does not fit all, and the architect should know that there are many project lifecycle approaches and methodologies to choose from. Each approach has its pros and cons, but all of them typically address the following project activities ...
Here’s a partial list of some of today’s popular methodologies ...
Unfortunately, a commonly used methodology in many shops is still the Code and Fix approach(re: Steve McConnell, Rapid Application Development, page 140).
The architect should be familiar with the following types of tests ...
For more information visit Visual Studio Testing
Software architects must be able to guide their teams in the various ways to estimate the following ...
Typically we start by estimating the size of the software product. This can be measured in any number of ways, for example, number of web pages, use-cases, objects, database tables, etc. Given an idea of how big the product is, the architect and developers will hopefully then have sufficient data to estimate the work effort (i.e. how long it will take to build the product). The estimated work effort can then be used to estimate the project schedule.
Estimating is both an art and a science. There are many ways to approach estimating; some of these are identified here ...
I highly recommend Steve McConnell's book Software Estimation: Demystifying the Black Art (Best Practices). You can also listen to him talk about this subject at Dr. Dobb's Journal.
Project management is essentially concerned with the following issues ...
Software architects should have some familiarity with all of the project management concepts mentioned above.
Should the software architect have deep skills in one language or another? You can see from my list that I believe an architect should have a broad understanding of a number of concepts. Given this, it may be difficult for the architect to be the top gun in the language or languages chosen for the project. Regardless, the architect should remain proficient in the languages used by the team.
I would also recommend that any architect be very good with SQL (T-SQL or PL/SQL) and XML.
So, there’s a list for you to shoot for. I decided not to attempt to justify what I put on this list and what I excluded; I’ll leave that exercise for you. Regardless, if you study these areas, I think you’ll go a long way to furthering your career as an architect. Good luck!
This series has been continued in the article What Does it Mean to be a Software Architect? - Part III
The Hard Skills are the Soft Skills The Many Species of Architects The Passage from Developer to Architect