Blog

Architecture Requirements are Ilities The business analyst(s) will collect the functional and system requirements. The architecture has other requirements. It is the job of the software architect to find and talk to the right people about them -- the system "ilities." An "ility" is a characteristic or quality of a system that applies across a set of functional or system requirements. So, performance is an "ility" because it is applied against some of the functional or system requirements. Anything that can be expressed in the form "for a set of functional or system requirements, the system must fulfill them this way (this fast, this reliable, etc.)" is an "ility." It is not always easy to help the users find all of the ilities that they are assuming apply to their current system or will apply to the new system. You might try using this list of ilities that commonly come up to jump start the conversation. Review i...

Introduction Me and my wife had some interesting conversations on Object Oriented Design principles . After publishing the conversation on CodeProject, I got some good responses from the community and that really inspired me. So, I am happy to share our next conversation that took place on Object Oriented Design Patterns. Here it is. What is a Design Pattern? Shubho : I guess you already have some basic idea about Object Oriented Design principles. We had a nice talk on the OOD principles (SOLID principles), and I hope you didn't mind that I published our conversation in a CodeProject article. You can find it here: How I explained OOD to my wife . Design Patterns are nothing but applications of those principles in some specific and common situations, and standardizing some of those. Let's try to understand what Design Patterns are by using some examples. Farhana : Sure, I love examples. Shubho : Let's talk about our car. It's an object, though ...

Introduction My wife Farhana wants to resume her career as a software developer (she started her career as a software developer, but couldn't proceed much because of our first child's birth), and these days, I am trying to help her learn Object Oriented Designs as I've got some experience in software design and development. Since my early days in software development, I have always observed that no matter how hard a technical issue seems, it always becomes easier if explained from a real life perspective and discussed in a conversational manner. As we had some fruitful conversations on Object Oriented Designs, I thought I could share it because someone might find it an interesting way of learning OOD. Following is how our OOD conversation took place: Topic: Introducing OOD Shubho : Darling, let's start learning Object Oriented Designs. You know Object Oriented Principles, right? Farhana : You mean, Encapsulation, Inheritance, and Polymorphism, right? Yes...

Introduction It has always been a goal of project architects to plan an effective strategy from the ground up in regards to an new application. All relevant factors are taken into consideration with respect to the application, from its design and layout to a functional website infrastructure. Pre- .NET strategies and design guidelines still effective now were developed with Microsoft's DNA (Distributed interNet Application) platform. This model successfully served the purpose of architecting N(any number of)-Tier (levels) applications. In its basic sense, as in most robust, distributed applications, you'll architect 3 main layers or Tiers: presentation, business rules and data access . Now, each independent layer within itself, is another issue altogether. Each one has its own methodologies regarding its perspective best practices. In other words, many factors will determine its proper design, efficient data access and visually pleasing presentation. That is why each Tie...