Pragmatic Architecture, DevOps, and Cloud Computing
jl.marechaux 060001NWA6 Tags:  rsa-dm pragmatic tools agile rsa rational agility-at-scale architecture 4,063 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.
jl.marechaux 060001NWA6 Tags:  agileadopt rational architecture agility-at-scale agile tools 4,731 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:  agile architecture pragmatic tools rsa agility-at-scale rational 4,520 Views
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.
jl.marechaux 060001NWA6 Tags:  alm rational agility-at-scale agileadopt architecture tools rsa pragmatic agile clm 4,565 Views
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 !
jl.marechaux 060001NWA6 Tags:  featured agileadopt agility-at-scale clm architecture alm agile pragmatic rational 5,402 Views
Today I am starting a series on ALM and Agile design (probably 4 or 5 different posts in the coming weeks).
A 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.
In 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 satisfaction.
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 change management.
The pragmatic architect is also a pALMatic architect:
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.
I have recently been designated an IBM developerWorks Contributing Author. As, they say, this is a "credential that represents your publishing achievements on developerWorks and the overall technical and educational value that your developerWorks contributions have provided, as recognized by industry colleagues."
I hope that the different articles that I wrote in the past have been useful for practitioners doing architecture, design, and development
jl.marechaux 060001NWA6 Tags:  alm rational agility-at-scale agileadopt featured agile architecture pragmatic clm 4,855 Views
[Previously on ALM and agile design..... The pALMatic architect]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.
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.
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.
For the 4th consecutive year, the Agile Tour (http://www.agiletour.org/) will stop in Montreal this Fall. With more than 450 attendees last year, the Montreal conference is the right place to meet Agile experts and practitioners.
For the first time this year, I am part of the conference organizing committee. I am very excited about it! I hope we will prepare a high quality and unforgettable event.
FYI, the call for speakers is now open. So if you happen to be in Montreal (Canada) on November 24 and you want to share your Agile experience, do not hesitate to submit a proposal.
Agile Tour Montreal conference