Category Archives: IASA

Agile, Architecture, General, IASA, Leadership, Product Owner, Scrum, Software Architecture, XP

Survey for Software Quality Attributes - Where Should We Focus?

6 Comments

I have been using a tool for some time with clients and teams to find out what software quality attributes the product development team should focus on in the project. ISO standard 9621 describes the quality attributes found in software. The following image shows the 6 categories and specific attributes contained within them.

ISO 9621 Software Quality Attributes
ISO 9126-1 Software Quality Attributes

Before I knew about this standard I would discuss how different quality attributes are in conflict with each other. For instance, if we write code that is focused on performance we lose some maintainability. It will be more difficult to read code focused on performance because readability will be sacrificed to some extent.

Now that I’ve known about ISO 9126 for many years, I made a simple spreadsheet tool to interview Product Owners, stakeholders, and software development team members with. Here is the Excel spreadsheet form of this tool:

Software Quality Attributes Rating Tool

Although a bunch of smart people have come up with ISO 9126, I found that modifying the software quality attributes rated in the tool worked more effectively with interviewees. This tool is not to decide what software attributes will be present in the software product getting developed. It is used to identify which software quality factors the team should put more emphasis on when making trade-off decisions during the project. Here is a list of the software quality attributes used in the tool:

  • Suitability - Functionality is suitable to all end users
  • Interoperability - Functionality interoperates with other systems easily
  • Compliance - Functionality is compliant with applicable regulatory guidelines
  • Security - System is secure: confidentiality, integrity, availability, accountability and assurance
  • Maturity - System components are proven stable by others
  • Fault Tolerance - System continues operating properly in the event of failure by one or more of its components
  • Recoverability - System recovers from failures in surrounding environment
  • Understandability - Able to use system with little training
  • Learnability - Supports learning of system functionality with little external interfacing
  • Operability - Ability to keep a system in a functioning and operating condition
  • Performance - Perceived response is immediate
  • Scalability - Able to handle increased usage on the appropriate amount of resources
  • Analyzability - Ability to figure out how the system functions
  • Changeability - Ability to change the system components to meet new business needs
  • Testability - Ability to create repeatable and specific tests of the system and potential for some to be automated
  • Adaptability - Ability to change out system component functionality quickly
  • Installability - Ease of installation and reinstallation
  • Conformance - Conformance to industry and operational standards
  • Replaceability - Ability to replace system in the future

Using the tool is quite simple:

  1. Emphasis Ranking: Have the Product Owner score each of the software quality factors from 1-5 (1 being less applicable and 5 being more applicable) in terms of the software product.
  2. Business Stakeholders identify 3 Must Haves - Ask the business stakeholders what are the 3 software quality factors they want most and stack rank them from 1 to 3
  3. Software Development Team 3 Must Haves - Ask the software development team what are the 3 software quality factors they want most and stack rank them from 1 to 3
  4. Capture Notes about Decisions - Use the notes column to capture any specific decisions about the software quality factors that would help the entire software product team come to consensus.
  5. Discuss Must Haves across Groups - Get the Product Owner, business stakeholders, and software development team members together to discuss and come to consensus on which software quality attributes they will focus on for this project.

Please let me know how you use this tool. There have been many teams that have taken up this tool and found it to be helpful for communicating what is most important from a software quality attibutes point of view in the project. Hope it does the same for you.

Agile, Architecture, General, IASA, Leadership, Product Owner, Scrum, Software Architecture, TDD, XP

What is Architecture?

1 Comment

Talk about a loaded term. Even the term itself, “architecture”, when used in the Agile community can start a heated discussion. When I was coordinator of the International Association of Software Architects Puget Sound chapter, the discussions about “what is architecture” caused passionate debate. I am sure this entry will get some interesting comments, as well.

I don’t believe that this entry will solve the question but I hope to at least give some focus for teams who are dealing with the structural integrity of their applications. First off, a definition of “architecture”:

architecture: noun - “the art or practice of designing and constructing…” or “the complex or carefully designed structure of something” or “the conceptual structure and logical organization of a computer or computer-based system”

Each of these definitions interests me but to put them to practice is quite difficult. They are left to interpretation about what is design, construction, structure, conceptual, and logical. Earlier interpretations of this term interpreted these to mean the high-level structure, architectural style, and finally the stuff that is too expensive to get wrong.

It seems to me that my interpretation is a bit different. Working with tools, practices, and processes over the past 15 years has guided me to a different conclusion. I believe that architecture is how it is SAID:

Structure - how the pieces (components) create a solution (application)
Alignment - the degree to which the application or enterprise structures align to current business objectives and strategy
Integrity - the components that provide stability to the structure (application or enterprise) (ie. automated tests and builds, service-level agreements, network infrastructure, etc…)
Design - a way to conceptually communicate the planned or implemented structure of a component, application, or enterprise (ie. system of names, XP practice of Metaphor, information radiators, etc…)

Using these as the basic building blocks for teams to focus their efforts can be helpful.

The structure is the reality of the solution’s construction. If the structure is too brittle or complex to support future needs then the structure is not sound. If you have been in the software development industry for even short period of time you have probably seen applications that are too brittle or complex.

If the application or enterprise structures are not aligned with current business needs then the value of those structures have deteriorated. We sometimes keep a specific architecture and force-fit new business needs into it because it once was the right architecture to have or we paid a bunch of money for it. Continual restructuring of our architecture to meet today’s business needs is important.

Providing supports to our structure allows for it withstand changes in the environment such as new business needs and updates in technology. Automated tests and builds help us keep the structural integrity of our applications intact while these changes are introduced into our applications and enterprise.

Communicating the conceptual structure of a component, application, or enterprise is important because it is common for new people to work on them and for those structures to interact with other components and applications. Getting someone up to speed on a component or application involves verbal, tactile, written, and visual examples. Much of what is needed can be kept in or close to the codebase along with conversations with existing developers. It is important to understand how components and applications are currently structure conceptually so we can discuss their interactions with other components and applications. For instance, should we connect via library, SOAP, RPC, or REST?

When I think of application architecture I want to focus on just a few principles:

  • Application architecture is about changeability, not longevity
  • Application architecture decisions should be made closest to where they are implemented as possible
  • Application architecture design is not only about our ability to design a solution but also knowing what components, applications, and solutions already exist
  • The value for change in a component’s, application’s, or enterprise’s architecture is directly proportional to the cost of not addressing

If the structure is not able to change as the needs of our business change then the solution will become a liability. If someone other than those who are constructing components and applications are deciding on architecture decisions then there will be important information lost in translation between the two. If we keep using the same design hammer (ie. always using 3-tier or IoC for everything) then we are not allowing the strongest solutions to emerge. The value of architecture can usually be described by the cost incurred if it is not taken care of.

Well, let the onslaught of comments commence. I have put out my ideas on architecture. There are many more out there to discuss and I am sure I will hear some of them. I will finish this entry with a quote from Martin Fowler’s “Who Needs an Architect?” article:

“I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important.”

IASA

July 2006 IASA Puget Sound Chapter Meeting

The Puget Sound IASA (Int'l Assoc. of Software Architects) welcomes Kim Cameron, Chief Architect of Identity from Microsoft, presenting on the topic of “The Identity Metasystem and Cardspace”. Details on this topic may be found at http://groups.yahoo.com/group/iasa-pugetsound-members/files/InfoCard.ppt.

The meeting will be held on Wednesday, July 26th at the following time and location:

EVENING:
6:30pm - 9:00 pm
Microsoft
15700 NE 39th St
Building 43, Room 1560
Redmond, WA 98052
Directions

These meetings are open to the public so please join us and bring your friends and colleagues. We hope to see you there.

IASA

Presentation on Space-based Architecture

We had a great presentation for the Puget Sound chapter of the IASA this month from Owen Taylor on the topic of “Space-based Architecture and the End of Tier-based Computing”.  What a great topic name!  I think that many of us out there know that the tier-based solutions were just a stepping stone to a new way of developing cost effective software architectures.

Many of my colleagues over the years know that I am quite taken by the power of the Jini/JavaSpaces programming paradigm.  Whether they agree or not (or even want to hear it again from me) I try to present how testing, development, versioning, and deployment are made easier with service-orientation.  GigaSpaces definitely grabbed the attention of those who attended (although attendance was low for each meeting, unbelievable since it was a sunny day in Seattle :).  By incorporating the service provisioning power of Rio into their product, they not only make Jini/JavaSpaces development easy but also gives enterprise class dynamic service provisioning.

The demos that Owen showed during the presentations were amazing, even though I have done similar things with Rio in the past.  I believe that Owen and GigaSpaces have told the story of the Jini/JavaSpaces programming paradigm incredibly well.  Something that I don't believe I have been able to do as effectively in conversation.  The throughput of the product and dynamic provisioning capabilities really stood out.  I want to thank GigaSpaces for giving such a compelling presentation to our local community.  Give it up for “Linear Scalability”!

IASA

June 2006 Puget Sound IASA Chapter Meeting

On Wednesday, June 28, 2006, the Puget Sound IASA will be welcoming Owen Taylor, Directory of Technical Communications at GigaSpaces, for two presentations on the topic of “Space-Based Architecture and the End of Tier-Based Computing”. The meetings will be at the following times and locations:

Wednesday, June 28th

DAY:
1:00pm - 3:00 pm
Seattle Downtown Public Library
1000 Fourth Ave.
Howard S. Wright meeting room
Directions

EVENING:
6:30pm - 9:00 pm
Microsoft
15700 NE 39th St
Building 43, Room 1560
Redmond, WA 98052
Directions

More details at http://www.solutionsiq.com/iasa.html. These meetings are open to the public so please join us and bring your friends and colleagues.

IASA

April 2006 Puget Sound IASA Meetings

On April 26, 2006, the Puget Sound IASA will be having two meetings presenting Cameron Purdy of Tangosol on the topic of “Distributed Caches: Essential Lessons”. The day time meeting will be held at the Seattle Public Library‘s central branch at the following time and location:

1:00pm - 3:00 pm
Seattle Public Library
1000 Fourth Ave.
Howard S. Wright Family & Janet W. Ketcham meeting room
Seattle, WA 98104
Directions

Seating is limited so please go to http://www.solutionsiq.com/iasa.html for reserving a seat.

We will also have our regularly scheduled night time meeting:

6:30pm - 9:00 pm
Microsoft
15700 NE 39th St
Building 43, Room 1560
Redmond, WA 98052
Directions

Both meetings are open to the public so please bring your friends and colleagues.

IASA

IASA Meeting Tonight - Managing Investment Across the Project Life Cycle

Tonight we are having our monthly Puget Sound IASA meeting on the topic of “Managing Investment Across the Project Life Cycle”. Here is the abstract for tonight‘s meeting:

Scott Came, Monica Yap, and Tamara Sulaiman will be conducting a panel discussion about managing investment in projects from conception to delivery. Scott will discuss how enterprise architecture can be used as a mechanism to guide enterprise technology investment planning, and will illustrate how state government is doing so. Scott will also touch on SOA, and how to view technology investments as the provisioning of capabilities rather than technologies per se. Monica Yap will be discussing how her project teams are meeting investment costs through lean development methods and portfolio P&L (profit & loss) to validate business value. Tamara Sulaiman will discuss how she manages earned value by applying waterfall calculation techniques to agile projects.

Meeting Location:
Microsoft Campus - Building 43, Room 1560
Jefferson Room
Redmond,WA
Map: http://research.microsoft.com/projects/gridforum/campus.gif

If you are in the Seattle metropolitan area tonight, come and check out the local IASA meeting. It is usually a place of great discussions and intelligent thoughts. I learn a lot while at the meetings. See you there.

IASA

Open Spaces in SIG Meeting

Tomorrow night we are having our monthly IASA (International Association of Software Architects) Puget Sound chapter meeting in the Jefferson Room, building 43 room 1560, located on the Microsoft Campus. We are going to be trying out a new way to conduct the meeting, “open spaces”.

We are deviating somewhat from one of the principles that there is no pre-planned topic or speaker. We are declaring two topics, “SOA Best Practices“ and “What is architecture?”, but we are not going to force these topics to play out for the entire meeting. The reason for the deviation was an attempt to get past the initial shock of that one might feel initially. Hopefully, by having a topic to begin with there will be a quicker initiation into the actual discussion.

I will have some paper available to the group which will hopefully contain some interesting thoughts at the end of the meeting. The ultimate intent is to drive the topics into something that the group decides is worth discussing rather than holding to the original topics. If this happens, I would call this meeting a success.