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 ...
- Requirements Definition
- Layering
- Fundamental Object-Oriented Concepts
- Modeling Techniques
- RDBMS Concepts
- Centralized vs. Distributed Data and Logic
- Software Methodologies
- Testing Approaches
- Estimating Approaches
- Project Management Fundamentals
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 ...
Requirements Definition
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.
Layering
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 ...
- Presentation
- Business Logic (a.k.a. Domain Logic)
- Data Management
Layers provide several benefits ...
- Encapsulation of similar functionality
- Tends to minimize dependencies between functions in different layers
- Promotes ability to alter or substitute logic in layers without need to change logic in other layers
- Facilitates reuse or sharing of logic across layers
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.
Fundamental Object-Oriented Concepts
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 ...
- Aggregation and Composition
- Interface Inheritance
- Delegation
- Overloading
- Reflection
If you want to be an architect and you’re not comfortable with these concepts, it’s time to get cracking!
Modeling Techniques
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 ...
- Class-Responsibility-Collaboration Cards (CRC Cards)
- Data-Flow Diagrams
- Entity Relationship Diagrams (ERDs)
- Flow Charts
- Network Diagrams
- UML Diagramming Techniques
RDBMS Concepts
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 ...
- Normalization Theory (up to 3rd normal form)
- When to Normalize and When to Denormalize
- Transaction Management and the ACID Concept
- Concurrency Management Techniques (e.g. pessimistic vs. optimistic locking)
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.
Centralized vs. Distributed Data and Logic
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 ofService 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 ...
- Perceived application responsiveness (for the end-user)
- Deployment issues
- The strength of the coupling between logical layers
- Network latency and performance concerns
- Serialization techniques
- Stale data and data replication issues
- System availability
- Re-entrant code
- Security
Distributed systems tend to introduce performance issues, so beware!
Software Methodologies
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 ...
- Identification of Business Case (i.e. project justification)
- Requirements Definition
- Technical Design
- Construction
- Testing
- Stabilization and Tuning
- Deployment
Here’s a partial list of some of today’s popular methodologies ...
- Agile: This moniker actually encompasses a number of methodologies including Scrum, Extreme Programming, and Feature Driven Development
- Spiral Development
- Waterfall: Yup, the grandfather of all methodologies is still alive and kicking. Regardless of what Agile fanatics might say, it is appropriate for certain situations.
Unfortunately, a commonly used methodology in many shops is still the Code and Fix approach(re: Steve McConnell, Rapid Application Development, page 140).
Testing Approaches
The architect should be familiar with the following types of tests ...
- Unit-Test
- Stress or Performance Test
- User Acceptance Test
- Regression Test
- Integration Test
Estimating Approaches
Software architects must be able to guide their teams in the various ways to estimate the following ...
- Size of Software
- Work Effort
- Project Schedule
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 ...
- Function Point Analysis
- Cocomo
- Wide-Band Delphi
- The Putnam Method
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 Fundamentals
Project management is essentially concerned with the following issues ...
- Schedule Management and Monitoring
- Status Reporting
- Risk Management
- Change Control
- Resource Assignment
- Budget Management
Software architects should have some familiarity with all of the project management concepts mentioned above.
What About Programming Languages?
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.
Summary
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
No comments :
Post a Comment