a practical approach to problems and affairs.
In software engineering, architecture
is a concept difficult to define precisely. One word is used for very different concepts such as functional architecture, data architecture, solution architecture or enterprise architecture. In addition, boundaries between architecture and design are unclear. Some say they are similar concepts. Others argue that they are complementary concepts with different levels of abstraction.
The real question is not what architecture is or is not. The real question is whether or not architectural analysis is useful for your project. And most of the time, if your are developing software-intensive systems, the answer is YES
. It is where pragmatism comes into play.
Many methodologies try to define the architectural work that you should complete. Some fundamentalists recommend that you define your architecture before you start your development. Dogmatic theoreticians say that architecture is a waste of time and that only code matters. Pragmatic architecture is about adopting the approach that works best for you. And what is best for you is not necessarily what is best for others.
The pragmatic architect focuses on essential concrete tasks and prioritizes the work according to the value it brings to the project. The pragmatic architect is open-minded and never refuses to consider a solution just because it is not the trend of the year. The pragmatic architect revisits the design as the development of the system progresses.
Your goals during p.r.a.g.m.a.t.i.c
- P: Promote collaborative work that involves all team members
- R: Reduce risks and uncertainties
- A: Adhere to minimalism and simplicity principles
- G: Gather key elements to outline the architecture during your initial timed-boxed iteration
- M: Modify the design throughout the development lifecycle to adapt to emergent needs
- A: Address both functional and non-functional requirements
- T: Try out theoretical concepts and leverage past empirical experience
- I: Invest in known requirement instead of hypothetical future needs
- C: Concentrate on tasks that support the development team
As architects, we must value pragmatism and practical experience
over dogmatism and theory.
Experienced Agile teams working on software-intensive systems conduct architectural analysis activities to mitigate technical risks and build better solutions. As a picture is worth a thousand words, those teams leverage diagrams for better agility. It is really efficient to share ideas and lead brainstorming sessions.
To create those diagrams, I can use a napkin, I can prefer a dashboard, or I can choose Rational Software Architect V8 (RSA) sketches. Why would I use RSA? I could think of four different reasons: easiness, collaboration, documentation, and flexibility.Reason #1: Easiness
RSA sketches are easy to create. There is no learning curve on RSA sketches. They use simple and informal notation, just like I do when I draw a diagram on a whiteboard.
Reason #2: Collaboration
Whiteboards are good, but not good enough when you need to collaborate with an extended team. How do you share your draws with people you collaborate with. The project stakeholders, the clients, the remote resources? Ok, you can always take a picture and share it. But what happens when you need to work again on the diagram later? Do you try to work on the picture file or you create the diagram again. It is not really practical nor efficient.
With RSA, you create sketches, you have them in your repository, and you can use them anytime, even through a web conference. You can collaborate efficiently with your local teammates and with external stakeholders. And of course, you can modify the sketches over and over again.
(I will write another post soon on how you can collaborate a step further with models on a shared repository)Reason #3: Documentation
I know, documentation in Agile projects is not popular. We need to focus on working software. But this is where RSA sketches are useful. I create them, they are stored in my repository, the history of changes is kept. It is the basis for light documentation. I can focus on my development activities.Reason #4: Flexibility
What can I do with a sketch on a whiteboard? I can look at it. I can erase or add elements. I can take a picture of it. And that's about it.
Now what can I do with an RSA sketch?
I can of course look at it, or add and remove elements. I can save it as a picture file (see, no camera needed this time).
I can also arrange the sketch appearance applying predefined or custom layouts (grid, hierarchical, horizontal....). This is always a challenge with a whiteboard diagram. You start the drawing and when you need to add more items, you have no space. Then you start writing so small than it become difficult to read.
With RSA, I can also link sketches to other sketches. Or create sketches form sketches elements. Then my diagrams are linked together, and a simple click opens the source or the target element. Really convenient to brainstorm at a high level first, before creating more precise diagrams for the most complex part of my solution.
Another nice RSA option is to convert my sketches into UML elements. So if I am using UML in my project, I can start with informal sketches and convert them when I need a more formal notation. Traceability between sketches and UML models is automatically created. I can even decide to mix informal sketches elements and UML elements in the same diagram.
RSA sketches are easy and flexible. They can support my Agile development and enhance my team collaboration. For further information on RSA sketching capabilities, see the free agile sketching training component on http://goo.gl/wGYtF
There are a lot of myths around agile software development. Agile teams need no discipline, no documentation, no planning are some examples of the misconceptions about agile. Here I want to share about two other myths regarding architecture and agile practices.
Myth #1: Architecture is not an agile practice.
Some say that agile teams don't waste time on architecture, they focus on coding the solution. This (false) statement is often made by people convinced that architecture has been intentionally banned from agile methodologies.
Of course, this myth is completely false. I checked my IT bookshelf for concrete proofs. I found specific recommendations for architecture on agile project from various agile though leaders such as Scott Ambler, Ken Beck, Alistair Cockburn, Mike Cohn, Ron Jeffries, Robert Martin, Mary Poppendieck, and James Shore. Check the recognized agile references. You will learn about architecture.
Myth #2: Agile teams don't do modeling
So myth #1 is declared busted: architecture is part of the recommended agile practices. And architecture is not only refactoring and test-driven development. Agile teams also conduct modeling activities.
Conclusion: Let's be pragmatic. As agile teams, we have to think about the structure and the behaviors of the solutions we develop. And very often, simple modeling sessions are very efficient to build better applications. Architecture is definitively a key activity of agile developments. It helps teams teams build better software-intensive systems.
Back from vacation.... During the holiday season, I had some time to read a couple of non-IT books, like Le bourgeois gentilhomme (The Middle-Class Gentleman). Molière wrote Le bourgeois gentilhomme in 1670. A key part of the play is when Monsieur Jourdain, the main character, discovers that he has being speaking "prose" all his life without knowing it (verse was more popular than prose at this time).
When I started my career as a software engineer (97), I used to consider myself as a lousy developer. I worked first with C++ and PoweBuilder before focusing on Java projects. No matter what the programming language was, it was always the same story. I had problems writing lines of code based on a written specification, while my colleagues seemed to be very productive. They were spending days coding features with no assistance, without even compiling their code. Remember that we are in 97-98. C++ and PowerBuilder are not interpreted languages, and the software specification is very often a verbose document. And most software development processes are waterfall.
My way of working was quite different. I used to write a few lines of code, to compile and test it immediately in order to verify that......it was not working as expected (usually with some ugly runtime error). Then I was refining the former piece of code to fix the error, and I was repeating this again and again until I was able to complete my tests successfully. Typically, I needed to test and rework my code several times per hours. Comparing myself to my more experienced teammates, I was ashamed of being such an ineffective developer.
Also, it was real difficult for me to apprehend the specification written by the business analysts. I was usually understanding the big picture, but not enough to be sure of the right piece of code to create. At this time, I was convinced that it was a result of my lack of experience. My colleagues seemed to be satisfied with the features assigned to them. They were working in isolation with just a specification document to help them.
Again, I had developed a specific technique to compensate for my inexperience: I was buying coffee all the time to the analyst team. I used to spend a lot of time (and money!) at the coffee spot with them, in exchange for their explanation. It was quite an expensive way of obtaining meaningful input, but I guarantee it helped me decipher the cryptic specifications. And after a few months, my regular “coffee discussions” were far more helpful than any document.
A couple of years later, I realized that my way of working was aligned with some agile practices. Just like Monsieur Jourdain, I was being agile for some time without knowing it. My daily (and expensive!) talks with business analysts, developers or DBAs were actually quite productive. And it was not uncommon to continue the discussion at my desk so that I can demo something. The different stakeholders were all providing early feedback to the feature I was trying to implement. And with my countless tests, I was actually improving the quality of my code, iteratively.
On the other hand, my teammate working in isolation were creating software disconnected from the business needs. End at the end of the time allocated for their development, they have never tested their code. What I was (jealously) seeing as an impressive way of writing code was actually a poor practice.
I am pretty sure that there are a lot of Monsieur Jourdain around us. Practitioners who leveraged agile practices far before agile became popular.
The good thing is that because agile is now mainstream, we no longer have to buy coffee for a discussion with stakeholders. Now it's part of the process, ..... for free.
If you ever worked in a project where a scaling factor applies (see the scaling factors description
), you know that an appropriate tooling can help a lot. To deliver a software-intensive system, agile teams need to collaborate efficiently in a complex environment. In many cases, a white board with sticky notes is not enough, so teams adopt specific tools according to their needs for iteration management, test automation, or continuous integration (just to name a few).
If you have experience in software-intensive system delivery, you also know that when your tool set is not adapted to the needs of your team, it becomes a barrier to adopting agile practices. Agile is a highly collaborative approach to software development. If your different tools are not integrated, you are wasting time managing the links between project assets manually instead of focusing on creating working software. I have seen many projects using spreadsheets or wiki pages to compensate for the lack of integration between their development tasks, business needs, design assets, and quality management systems. It is a time consuming and error prone process. And when you need to figure out the impact of a changing requirement on a piece of code, it takes hours where it should only take minutes.
Open Services for Lifecycle Collaboration (OSLC
) is an open community creating specifications for integrating tools. These specifications allow conforming independent software and product lifecycle tools to integrate their data and workflows in support of end-to-end lifecycle processes.
With OSLC, your team can link elements from your defect tracking tool, your requirements management tool, your test management tools, and your design management tool. You may argue that traceability already exists with tooling platforms provided by some vendors. True. But what if you have a task tracking tool from vendor A and a test management tool from vendor B? Then integration no longer exists, or relies on some proprietary mechanisms. Do you really want to restrain your options to one unique vendor.
OSLC specifies a minimum amount of protocol to allow independent tools to work together relatively seamlessly. You can have quality management tools from vendor A and decide to use requirements tools from vendor B. Both will be integrated if they comply to OSLC. And later one, you will also be able to acquire another OSLC tools from vendor C without compromising your lifecycle integration.
So how does OSLC help agile team? Simply by enabling integration between lifecycle tools. If your team members must collaborate, your tools must work together too. Integrated tools help agile teams react quickly to changes and deliver software frequently.
(Watch the IBM OSLC video on YouTube for more details: http://www.youtube.com/watch?v=B2vqL8fujgE
If you ever worked in a project where a scaling factor applies, you know that appropriate tooling can help a lot achieve your objectives. But on the other hand, tools are often identified as impediments for agile adoption.
The Agile Scaling Model
defines several reasons why you may work in an environment where core agile practices are not sufficient. But even in such an environment, you want to ensure your product owner, your scrum master, your development team, and your stakeholders collaborate efficiently through sprints and releases.
IBM Rational provides an ALM (Application Lifecycle Management) for disciplined agile teams. Based on Jazz, the platform integrates requirement management, design management, quality management, and change management. Team members and stakeholders have access to the same project information and assets from a web browser. Anytime, from anywhere (distributed teams will appreciate!). They can collaborate through a centralized platform., The Jazz repository provides real time status on project progress. And the team can quickly react to changes by leveraging lifecycle integration and traceability, dashboards, queries, impact analysis, an reports.
Because the ALM platform leverages OSLC, you can even integrate with other OSLC compliant vendors. No more vendor lock-in. No more silos. Everyone working together to deliver better software. This is agility for ALM !
Today I am starting a series on ALM and Agile design (probably 4 or 5 different posts in the coming weeks).
bit like humans, software-intensive systems are conceived, come to
life, grow, evolve, do their job to contribute to business goal
achievements, are retired, and die. Application Lifecycle Management
(ALM) is the process of managing a system throughout its entire life.
small teams and simple environments, core agile practices are usually
enough to manage applications. For agility at scale, things are a bit
more complicated. ALM is often defined as an approach that integrates
disciplines as diverse as requirement management, design management,
quality management, and change and release management. Benefits are
obvious. ALM breaks down functional silos and promotes collaboration and
role-focused views of the application lifecycle. The entire team gets
greater insights into the project. Actionable information leads to
better productivity, improved quality.... and enhanced customer
Design management is a key building block in ALM.
The pragmatic architects do not work in isolation (read more on Pragmatism in architecture
. Those completing
architecture and design tasks want to understand the business needs
(requirement <--> design). They also have to make sure that the
design supports the implementation of the solution (design <-->
code). And design is eventually validated by some tests to validate its
quality (design <--> tests).
In other words, design
participates in lifecycle traceability. During the life of the
application, the pragmatic architect evolves and refines the design to
meet changing requirements and new technical challenges. And the
pragmatic architect also ensures that the design information is
available for efficient requirement management, quality management, and
architect is also a pALMatic
- A: Adapt to changing requirements and new technical challenges
- L: Link design to other lifecycle artifacts (requirement, test, code, changes)
- M: Manage design information to help other ALM stakeholders
Design management is an integral part of ALM to
deliver software-intensive systems in a complex environment. The
pragmatic architect manages design information and conducts design tasks
for successful and collaborative ALM.
[Previously on ALM and agile design..... The pALMatic architect
Agile teams develop software iteratively. The product backlog lists all the stories to implement and the team decides which ones they will address during the next release or iteration. In an ALM environment, teams want to plan and align their activities across all the disciplines, including requirements, design, development, and tests. The real challenge is to identify the right set of features to develop first. Any mistake in the priorities will lead to plan commitments that you will not be able to deliver. For most teams, business value is an important factor to prioritize the product backlog. But other aspects must also be considered, such as risks and dependencies.
Seasoned agile teams want to address risk early in the process to remove uncertainties as soon as possible. When a story may imply some technical challenges, it is a safe approach to increase its priority. Also, pragmatic practitioners know that some dependencies may exist between stories. Sometime, a high priority story can only be implemented once the work of a related story is completed. So when a new iteration starts, it is important to identify the most risky stories and to uncover the dependencies between features. This information influences development priorities for the team.
How can you identify risks and dependencies? In most software-intensive systems, practitioners must apprehend the structure of the application before they commit to deliver any change. They must also understand the impact of a new story or a change request on the existing code. This is where design helps. It provides insights to the team so that they prioritize the backlog based on concrete information. With a quick access to a design element or a diagram, team members can decide if the priority of a story must be increased. They may even conduct a brief brainstorming session to better understand the technical challenges.
Design management is an integral part of ALM to deliver software-intensive systems in a complex environment. During planning activities, agile teams refer to design information to make rational choices. The backlog is prioritized as the team takes into account the business value, the risks, and the dependencies.