Search My Postings

Friday, January 27, 2017

What is the difference between software architecture and software design? 

In my view, software architecture is list of significant decisions taken on key business requirements (both functional and non-functional) and decision trade-offs between different viewpoints and stake holder interest. So Architecture = Decisions + Views Wherein design is how to implement those high level decisions. In way architecture provides reference context to design. Usually design is technology specific and implemented by experts in specific technology. I tried to compile few the comments from my practice on conceptual differences between architecture and design.
 1) Well in one liner, SW Design implements SW Architecture. SW Design typically covers functional requirement whereas, SW Architecture covers non-functional aspects (but not limited to) of it e.g. Scalability, Availability, Performance etc. So, in another one liner SW Architecture and Functional Requirements are input for SW Design.
 2) Architecture sets the principles, standards, constraints, and high level patterns of how solutions should be designed. Design sets the detailed implementation patterns and language specific standards of how the solutions should be built within the scope of a particular set of requirements.
 3) It is the collaborative effort between the delivery teams and the architects that comes up with the architecture for the system. It's a joint partnership with many gray areas. Key aspects of architecture are: software components and their composition, visible properties, Relationships, significant decisions with a large impact, providing a shared understanding and line of sight to enable collaboration, maximizing reuse, and defining the approach need to meet non-functional requirements.
 4) Architecture is abstract, conceptual detail. Design is concrete implementation. Architects plan to design; designers design to plan.
 5) Architecture is WHAT, Design is HOW
 6) Architecture is defined based on Organization's Strategic goals, be it technology or business, by laying out what makes up the IT infrastructure of an organization and serves as blueprint or framework for all application solutions within an organization. Of course, it is a design by itself. However, Design, which usually refers to application solution design, is the application of Architecture to develop solutions that solve a particular business problem of the organization.
 7) SW Architecture defines the components, interfaces, behaviors and its interactions in a SW system or SW package in a generic way that does not specifies a particular vendor technology/platform. The SW Design specifies the realization of the SW Architecture in the context of a particular software technology or platform.
 8) The primary feature of an architecture is to define structure and a structure is necessary in order to handle complexity (e.g. many modules, sub-systems, interrelated systems, etc.) and structure is also necessary to be able to evolve the "system". Architecture can (and should) depict the phases or releases (whichever you prefer) of systems and enable the transition between them. Software design constitutes the direct or indirect production of code in accordance with the architecture and functional specification. The particular code for a given functional module could be different between releases, or between identical functions that require different non-functional behavior, or different modules could share the same code for equivalent functions. A s/w designer knows how to get the best out of the particular language and platform to deliver the architectural and functional specifications and the s/w architect knows how to put all the components together, over a time span, to achieve the business goals.
 9) Architecture of any kind, is simply abstracted, structural design at the highest level in any context. It typically involves the specification and just positioning (and real-world compromises) of the major components of any system. Architecture is concerned with the 'black box' characteristics of the components rather than the detail of their internal functioning. The latter is detailed design and engineering, although there is no hard boundary to this other that what's indicated by the architecture itself. However, often an architect will need to explore a level down to ensure feasibility, particularly for relatively unknown or uncertain components. For software in particular, the scoping and bounding of highest level components is as much art (intuitive ability) as it is engineering.

Friday, July 15, 2011

Saturday, June 25, 2011

Can Big Upfront Architecture Document will be beneficial for the team

At times big upfront architecture document say about more than 50 pages document may not grab the attention of developers/other concerned parties. So we architects should be aware of creating architecture documents which are short and to the point. There is no point in creating big documents which no body interested in to know/refer. In my opinion, the architecture document shall be
1) Shall be simple and shall contain key architecture decisions. In my opinion with few UML diagrams and brief description should solve the purpose.
2) Update the document only if deemed to be necessary/otherwise don't update

Sunday, December 12, 2010

My Reading List

This is the live content I will be using as my reading list.

- Software Craftmanship - Currently reading
- The Design Patterns Small Talk Companion - Under progress
- Expert One on One - J2EE without EJB - Finished
- Agile and Iterative Development - Finished
- TOGAF 9, Pocket Guide - Finished
- Agile Project Mgmt with Scrum - Finished
- Java Server Faces - Currently Reading
- Applying UML and Patterns - Finished, but needs some revisits
- Evolutionary Arch and Design - Currently Reading
- Architecture Principles - Finished
- Information Arch and User Experience - Currently exploring
- Architecture Review (ATAM, SARA) - Currently Reading

The Toyata Way - Currently Reading
Mega Living - Currently Reading
Discover Dimond In You - Finished
The World is Flat - Currently Reading
The Malgudi Days - Currently Reading
The Koutilya Arthasastra - Currently Reading

Concrete skills

Each and every individual professional in the IT must have self analysis on some concrete skills. Here what I mean by concrete skills is nothing but deep understanding on the subject which can be easily appreciated and recieved by your collegues.In other words, these concrete skills demonstrates your authorative knowledge and experience on the subject. For example, following are few subjects which myself analysed on my professional life mostly reflects my day to day actvities.

Mostly concrete
Architecture, OOA/D, General Programming skills, Review, Agile engineering practices, Java/J2EE, build scripts, unit testing, Documentation, Presentations on different subjects, Leadership, Pre-sales etc.

No so concrete
Spring, JSF, Javascripts, CSS, HTML, SQL/PL-SQL, Installations, Debugging,
network, protocols, User experience etc.

This kind of analysis puts you to pritorize your free time towards reading.