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)
Pragmatic Architecture, DevOps, and Cloud Computing
Matching: architecture X
jl.marechaux 060001NWA6 Tags:  agileadopt rational architecture agility-at-scale agile tools 4,719 Views
jl.marechaux 060001NWA6 Tags:  rsa-dm pragmatic tools agile rsa rational agility-at-scale architecture 4,051 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:  ebook tools featured agility-at-scale rational rsa architecture 8,164 Views
Back in October, I published two papers on how to define application architectures with Rational Software Architect V8.
In addition to the web version of the articles, I have created e-books for on-the-go readers. Nothing too fancy, but simple books compatible with most eBook reader tools. The PRC format is quite generic and works for Kindle or for readers on PC, Mac, and Android. The EPUB works for iPod/iPad/iPhone and Adobe Digital Editions.
- Download the epub ebook
jl.marechaux 060001NWA6 Tags:  agility-at-scale featured pragmatic tools rational architecture agile agileadopt 23,010 Views
\'prag-me-ti-zem\: 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 architectural activities
As architects, we must value pragmatism and practical experience over dogmatism and theory.
The posts in this blog are written by Jean-Louis Marechaux (aka