Software Architecture Lifecycle

one my recent Architectural consultancy assignment, questions were raised for architecture life cycle. There is lot of literature about software development life cycle (SDLC) but hardly any on software architecture. In response of these questions I thought of documenting the Architecture Lifecycle.

In the proposed lifecycle I have broken down Software Architecture Lifecycle in five steps:

Step 1: In this step Software architect and stakeholders are identified and their interaction starts.

Step 2: This step is collection of three sub steps which result in design, documentation and analysis of architecture. These three steps are not very distinct and executed in iterative fashion.

Step 3: In this step realization of architecture take place. Different applications and products are designed and implemented as per the over all architecture.

Step 4: In this step learning from previous steps, historical records, industry trend, business requirements are constantly evaluated and fed back to step 1.

Step 5: This is last step of any architecture. This step is executed in case of obsolesce of current architecture. This step does not executed in one go but in baby steps. It means that parts of Architecture get retired and new things get into it. In rare cases step is executed in totality.

These five steps are not very distinct and get executed in iterative fashion.

Service Design Principles

As we all know SOA is an architectural style to building systems from autonomous services. So what are services? Services are software programs that interact with well defined messages over network.

Keeping these propositions in sight, SOA ecosystem robustness and architectural value is greatly influenced by how Services are designed as consumer and provider.

While designing a service one should consider following perspectives:

1. Provider perspective
2. Consumer perspective
3. Implementation perspective
4. Administration perspective

The design goal service should be similar to any software system. These are:

1. Loose coupling: Basic objective of SOA
2. Encapsulation: Basic objective of Object Orientation
3. Polymorphism: Basic objective of Object Orientation
4. Autonomy: Basic objective of SOA and distributed computing
5. Orthogonality: Basic objective concept of layered architecture and Object Orientation
6. Idempotency: Basic concept of distributed computing
7. Cohesion: Division of labour and specialization

So partial list of design and building principles of services:

1. Services should be designed for availability and stability.
a. Once services are deployed in production environment change in their availability & scalability is undesirable
b. Infrastructure support for service should be continually evaluated and updated to cater increased load and stress.
2. Service configurations are designed and built for change
a. With the passage of time and changing business needs, service configurations changes with respect to functional and non functional aspects.
b. Service’s deployment options with respect to physical location, policy, topology changes
3. Service invocations are subject to famous EIGHT fallacies of distributed computing.
4. Use Object based ( programming language - Java objects or XML documents à object/document may represent business event not actual business documents) operation/method parameters and return type
5. Keep service surface area minimum. The more operations/methods a service exposes the more difficult to manage them.
6. Avoid Service Hell
a. Service granularity must be managed. Too coarse grained service hinders re-usability. Too fine grained services create a jungle of services.
b. Service versioning should be managed
7. Adopt pessimistic view while designing a service (consider both views: Provider & Consumer)
a. Design and build services with extensive exception and error framework in foundation.
b. When service acts as provider validate one and all inputs
c. When service acts as consumer design for unreliable provider with respect to availability and performance
8. Services contract should be deployed & versioned independent of:
a. The system they are deployed
b. The inter implementation
9. Idempotency (Repeatability): Service must be idempotent with respect to one and multiple consumers.
10. Service nomenclature should be in sync with business not with development team. This especially true for business services.
11. Services must be stateless.
12. Services should have multiple interfaces either using ESB or without it.
13. Service should support patch like mechanism to facilitate upgrade.
14. Service operations/methods should be designed for concurrency.
15. Carefully decide (use both business and technical perspectives) which service should have compensatory service
16. Avoid transactions
17. To track state during long running service use track identifier at each milestone of process.

Book Review: Collective Intelligence in Action by Satnam Alag: Publisher- Manning: ISBN- 1933988312

Collective Intelligence in Action covers newer ideas of software architecture in very concise and beautiful way. This book is little bit different from traditional software architecture books. It covers web 2.0 software applications especially customer facing. It draws examples from best of the breed applications available in web 2.0 world.

Collective Intelligence in Action is divided into three parts. Part one covers collection of data – symmetric & asymmetric from web 2.0 applications. This part covers extensively tags, blogs and web crawling. Part two talks about usage of data collected in part one. This part of book introduces concepts of Data mining for green horns. This part covers both data mining with respect to relational data as well as textual data. Part three of the book tries to build a recommendation engine from the learnings of part one and two.

Collective Intelligence in Action is must for software architects veterans as well as aspiring.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: A competing book is Programming Collective Intelligence: Building Smart Web 2.0 Applications by Toby Segaran.

One can get more information about book from:

1. Amazon
2. Manning
3. Book forum by Alag
4. Slashdot

Software: Architecture and Product Design

Yesterday, I had an interesting discussion while sitting at the bar with fellow architects and product managers. The discussion was about Software Architecture and Software Product Design. From the discussion I have drawn following observations:

Software Architecture governs fundamental structure, communication model among components/module and non functional aspects like: scalability, resilience, reliability, deploy-ability, maintainability, security, standard compliance, technology base, etc.

Product Design determine observable aspects of an software product like feature set, usability, visual aspects, installation ease, configure-ability, business model support, etc.




Certainly these observations were made after a couple of drinks.

Single Service: Multiple Interfaces – Service Design Pattern

In one of my recent project, I encountered an interesting challenge. There was couple of services. Each of these services needs to serve various consumers which have diverse background. Few of the customers were interested in one type of interface (Web Service) while other set of consumers were demanding SOAP over JMS, CORBA calls and few more. This was interesting situation. My SOA instinct told me to look for solution in ESB. But none of ESB was able to provide such diverse channel transformation. Then I discovered that solution lies some where else.

“A service should have multiple interfaces in terms of technology & business needs if ESB fails to provide.”

I realized from analysis of various other projects that this is a pattern which is quite prevalent but not explained in detail. I call this pattern Single Service: Multiple Interfaces.






Discovery of this pattern also leads to another pattern – Separation of Service Implementation and Service Interfaces. I will discuss this pattern in detail in some future post.

Performance Management: SOA Ecosystem

Dimensions of Performance Management in SOA ecosystem are:

1. Capacity Management
2. Performance Tuning
3. Profiling & Analysis
4. Performance Bottlenecks
5. Architectural Analysis
6. Tools and Platform limitations
7. Data availability
8. Data discrepancy


Factors to be considered while doing Performance Management

1. Workload: Different forces that acts on a system which affect a system’s performance
a. Concurrency: Concurrent usage of shared resources like processor, memory, network, connection pool, thread pool etc lead to a queue which affect response time as well as throughput.
b. Session Length: Longer session time means higher usage of resources. High level of Concurrency and Session length are sufficient to stress a system.
c. Data in Session: More data in a session coupled with High concurrency and Long Session length is deadly combination for Performance Management.
d. Break Time: This represents the time taken by user to initiate subsequent request. This parameter plays crucial role in working with concurrency and session length.
2. Usage pattern: Usage pattern represents the variation in usage of system by various actors – human and machine over a time period in real time production environment. To understand Usage pattern volumetric studies are good source of information.
3. External Interfaces: In SOA ecosystem definition of external interface may assume various meaning. One can assume that interfacing with services within an enterprise/LOB will be treated as external interface while another analyst/architect might not agree. Things become more complex with involvement of B2B and Business to SAAS cases. And never forget normal I/O operations.
4. Infrastructure: In a SOA ecosystem Infrastructure always plays a crucial role in Performance Management due to its very nature. Few of the attributes of infrastructure are: network capacity; Server sizing in terms of CPU, RAM, cache, etc; load balancing; fault tolerance; virtualization; etc.
5. Persistence Layer: The volume of data to be read and to be written to persistence layer. Persistence layer primarily consistence of three systems:
a. RDBMS
b. Hierarchical Databases ( e.g. LDAP)
c. File system

Performance Management & SDLC