On February 14th has been published the list of the most-loved Rational articles in 2011. Even if I am not sure what “most-loved” means here (can you really be in love with a technical paper??), I am glad to see that the one I wrote on architecture with RSA 8 is on the list. (http://www.ibm.com/developerworks/rational/library/define-application-architecture-rational-software-architect-1/index.html)
But I must that this popularity raises a couple of questions. Published last October, the article has been viewed almost 15 000 times. I also created e-books from the article and they reached over 200 downloads since November 22, 2011. So why is this article so popular? Is it because it talks about RSA 8? Or because it covers an agile practice, the evolutionary architecture? Maybe there not enough enablement resources available on RSA. Maybe architecture is not covered properly by the agile community?
I'd like to have more feedback from the community. If you read this post, do not hesitate to contact me.
Pragmatic Architecture, DevOps, and Cloud Computing
Matching: rational X
jl.marechaux 060001NWA6 Tags:  agile architecture tools pragmatic rsa agility-at-scale rational 4,473 Views
jl.marechaux 060001NWA6 Tags:  agileadopt rational architecture agility-at-scale agile tools 4,684 Views
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)
jl.marechaux 060001NWA6 Tags:  rsa-dm pragmatic tools agile rsa rational agility-at-scale architecture 4,018 Views
Success in agile development comes from teamwork. No matter which agile process you apply, collaboration is always at the heart of recommended best practices. Quality systems are also based on good design to make them easier to maintain and extend. The Better quality and agility with collaborative design article demonstrates how Rational Software Architect Design Manager enhances collaboration on design activities.
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).
Architectural analysis is a set of activities to build and improve the software architecture of a system. When conducted iteratively, this architectural thinking helps uncover and address issues during software development without requiring significant up-front architectural effort. Architectural analysis activities are crucial for every software-intensive system.
Despite what dogmatic agile development coaches might say, I believe that there is no successful software development without architectural analysis.
I had a strange conversation with an IT professional last week. To preserve his anonymity, let's call him Oleg.
Oleg: Pretty well, JL. I joined a new project two months ago. It's an agile team and I like it very much.
JL: Glad to hear that. What kind of project is it?
Oleg: We are developing a new solution to enrich our existing internet banking application. Our new component will integrate services from several departments and even business partners.
JL: Sounds like an interesting challenge. Are you working on the architecture of this new solution?
Oleg: No, we don't do architecture, we are an agile team.
JL: ??!!?........ (speechless....)
Oleg: We focus on developing a set of services to enable the integration.
JL: Ok, I understand that your primary objective is to deliver working software but integration of services from different sources must not be easy. How do you define the structure of your component? How do you identify the different services needed? How to you mitigate risks?
Oleg: Well, it took two weeks before the project really started. Just the time to obtain the buy-in from the business sponsor and assemble the whole team. It was a great opportunity for me and some colleagues to start thinking about our new project. We addressed some of these questions at this time.
JL: I see... so you pictured the technical solution during the project warm-up. And how are you evolving your architecture during your sprints?
Oleg: Well, as I told you, it's an agile team. We do test-driven development and refactoring all the time, but we don't waste time on architecture.
JL: You mean that because you are an agile team, then you don't...THINK?
Oleg: Don't get me wrong. I work with brilliant people and we have brainstorming sessions all the time.
JL: Ok, so you are doing architectural activities, right?
Oleg: Well yes, but the client does not want to pay for architecture. So we don't really publicize this. We keep it secret in our war room and we bill our time on development tasks.
JL: I see. Architecture is really part of development sprints anyway, so you bill your time at the right place. Just curious, are you doing modeling at all?.
Oleg: Of course we do, because a picture is worth a thousand words. It helps us a lot during our brainstorming sessions. And we have a lot of short brainstorming sessions during the sprints to tackle new technical challenges uncovered. But again, this is not something we expose too much as the client does not pay for diagrams.
So what did Oleg tell me exactly? He stated that on his project, team members are not doing architecture because they are following an agile process. But then he explained that before their first development sprint, they spent some time to envision the architecture.So the good news is that Oleg's team is thinking about the new solution that they are developing (the bad news is that they seem ashamed of their architectural work).
Oleg also told me that his team is not officially doing architecture during sprints. But he also confessed that they are hiding to create models, as if it is some sort of perversion. Their models or sketches are considered helpful for their just-in-time modeling sessions during sprints. It is how they refine the architecture of their software-intensive system over time.
Of course, you can not deliver a system if you keep thinking about it forever. Architectural work must be integrated to the development lifecycle. Architecture is intentional because you make deliberate decisions based on what you know when you start a project.
Architecture is also emergent because you always uncover new technical challenges during development sprints.
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.
jl.marechaux 060001NWA6 Tags:  tools sketch rsa agile rational featured agileadopt 7,982 Views
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.
jl.marechaux 060001NWA6 Tags:  distributed rational agility-at-scale collocated pragmatic 6,665 Views
Distributed teams are often defined as teams with members in different offices, cities, or countries. Compared to collocated teams, they need more disciplined approaches to address the specific communication and collaboration challenges that they are facing. But geographically distribution is not the only factor to consider. Some collocated teams may fail in their agile endeavors because they do not their working environment.
Let's take the (fictitious) example of SatoriGeeks, a small company specialized in innovative solutions for the finance industry. They have a team of 6 people to develop their current solution. They all work at the SatoriGeeks office in Montreal, Canada. They have an open space to sit together for better collaboration, they have scheduled daily meetings for better progress status. They have also adopted a whole team approach with cross-functional people to maximize project success.
What can go wrong with this small collocated team? Their working environment may actually be more complex than it appears at first glance.
Marie, the product owner, is often visiting customers to understand their concerns. On a typical week, it is rare to see her at her desk. Simon, a team member, had a new baby girl last year. To balance work and family life, he is working from home twice a week. Rachel has flexible working hours (she lives in the Montreal south shore and tries to avoid peak hours to cross the bridge). Thomas had a knee injury playing tennis a couple of months ago. Since the beginning of the project, he must visit the physiotherapist twice a week during working hours. And he works from home when the knee hurts to much.
So for many good reasons, key members of the team are not always able to meet in the same workspace. Communication is affected, collaborative work is not as effective as it used to be. The team should consider itself as a distributed team because they have flexible working hours.
Flextime and flexplace has become mainstream in many organizations. It is too often considered as an human resources matter only, although flexible working hours affect project teams. Even if they are small and collocated, teams like SatoriGeeks would benefit from a more disciplined agile process to facilitate collaborative.:
Flextime and flexplace should lead collocated teams to consider some agile practices usually adopted by distributed team.