Achieving Product Excellence - Part I
Tags : Modern Technologies, .NET, ROI, Software Modernization, Modularity, ilities
Product Development attributes for market-competitive software products
“Modernizing your software product” highlights the need to migrate your products to modern technologies like .NET and justifies the ROI from such a move.
This is a three part follow-up series, in which we discuss the technical aspects involved in delivering a world class product. The concepts discussed in this series are targeted at CTOs and Architects. They are applicable to all kinds of software systems, but here an attempt has been made to package them in a product-development scenario, relevant to ISVs.
Before we jump into the nitty-gritty’s surrounding the architectural pillars that hold up world-class products let us look at what really makes a product globally competitive. A product is “a ready system”. The key to a “product” is that “it just works”. To convey that impression to your customers, it is expected to behave in a certain way. A great product:
- Works well with a wide variety of configurations
- Can be installed easily
- Has frequent updates to respond to changing needs and market requirements
- Performs better than your competitor’s product
- Can cope with the increasing needs of your client organization
In tech-speak these qualities correspond to product attributes like performance, scalability, security, maintainability, modularity, extensibility, and importantly – usability, or as we like to call them – The ‘-ilities’!
The “-ilities”
By the end of the series, we hope to have discussed the “-ilities” underlined in this diagram which shows the how they are interrelated. Using these set of attributes we will come up with a list of DOs and DON’Ts in designing and developing a software product. This discussion will use references to existing and upcoming technologies and concepts wherever necessary. This will help you come up with a plan of action for modernizing your software product.
We start this series with “modularity”. “Modularity” is not really an attribute of the software product itself, but an approach followed during the development process. However, the importance of modularity and its impact on the other attributes is so great that it warrants a discussion of its own.
Modularity
Modularity is not a new concept. It’s a divide-and-conquer approach which is used to make the software development process and the system more manageable. What we will discuss here are two concepts of modularity, often misinterpreted to be one and the same thing , layers and tiers.
What is a layer? A layer is a logical separation of responsibility within the code.
Separation of responsibility means the code within a certain layer will serve a specific purpose and will interact with other layers in the system only through well-defined interfaces
There is no restriction on the number of layers your product should have. You can create as many layers as you want. Layers are useful for your product in many ways and usually bring no downside. However, you should exercise due care in deciding the function of a layer. Try to avoid any ambiguities and mixing of responsibilities between layers.
In .NET, a layer typically translates to a Visual Studio project –a class, a component or an assembly.
If you would like to have one of your development teams to be focused on the user interface of your product, you could make a User Interface layer. Similarly, the team that best understands the domain would work on a layer that abstracts the business logic of your domain.
In the context of abstraction and layers we usually use the ‘KNOW ABOUT’ method.
As you see, there are four layers in the above diagram. The “responsibility” of the presentation layer is to present an interface to the user. In order to do this, the ASP.NET pages or windows forms that constitute the presentation layer, need not “know about” a data store. To this layer, it doesn’t matter whether or not a database exists. However, it should “know about” the business domain model. The objects. Things related to the domain. Purchase Orders, Books, Inventory. It knows a business layer exists, but its understanding of the business layer is limited to the interface exposes by the BLL and the messages pass to and fro.
The business logic layer should “know about” the business rules. For example, a business rule could be that the same book cannot be issued to two people or that the delivery should be within 5 days. This layer also does not know about things like databases and connection strings. It does not know about the presentation layer.
The simple rule is, layers hide the complexity in your system. Making your development very easy. So when developing a product, the first thing that you should do is to have well-defined interfaces.
What is a tier? A “Tier” is a unit of deployment. It is usually a physical boundary. For example, a memory boundary where two processes are running independent of each other or a physical network boundary where two systems talk to each other over a communication channel.
So just like a layer makes it easy for you to distribute work and neatly organize your code, a tier allows you to neatly organize your files, services, network ports, creating a different kind of boundary.
As you can see, the same set of layers can be deployed in various configurations, in different kinds of setup. This is why layers were made in the first place. So a set of layers together in the physical world, becomes a tier.
The decision to create a tier or not, depends on many other factors including performance requirements, ability of a particular application layer to scale, hardware resources available etc. We will cover these topics in the next part of the series.
The definition of layers and tiers as presented above, will be extended to explain Service Orientation and a reference architecture for higher system performance and maintainability, in the following parts of this series.
Achieving excellence in anything doesn’t happen overnight. Starting with the right concepts is vital, more so is the discipline in execution. Do share your thoughts and experiences!
Send your comments to Nishith.
