Feeds:
Posts
Comments

Archive for the ‘Software Architecture’ Category

Scrum by definition and design is meant to provide an alternative project management framework to traditional waterfall method. As one of the most used Agile methods, Scrum is non prescriptive but rather focusing on fostering team collaborative effort to achieve short term objectives following a relentless steady rhythmic work style.

Sprint after sprint team keeps shoving User Stories from the backlog to the development mill rotated by the collective effort of the team.

However, in the rush to finish the current tasks, quality can be easily overlooked and irreversible technical dept may accumulate unless consistently and actively monitored and controlled using a defined process such as the one I suggest here.

Again, four and three, four meetings types and three artifacts are the only rituals the Scrum Guide offers!

In practice, it is necessary to build on the framework offered by Scrum in order to avoid low quality deliverables that may occur by the mechanical application of the basic method.

Engineering practices that focus on quality borrowed from Kent Beck’s Extreme Programming (XP) is a good option here!

From those, Test Driven Development (TDD) , and Continues Integration (CI) are among my favorite recommendation to add to your Scrum practice.

Another example of an aspect of Scrum where the framework provides only a skeleton to be fleshed, is Architecture!

Unlike a method such as Rational Unified Process (RUP) whose “Elaboration” phase focus on realizing architecturally significant use cases producing what is called an “Executable Architecture”, Scrum doesn’t say much about how to Architect for a team that develops using Scrum? All what it says is that the team should decompose the system into shippable pieces, and deliver a piece per sprint.

In the last workshop I attended and organized by Egypt Scrum community, I started a discussion with a colleague about shipping a usable product every sprint and if that is really possible? My colleague insisted that time to market mandates shipping every sprint. I asked what type of projects she was working on, she replied that it is an upgrade for a layer of an existing software.

Oh yes, for such a project where you upgrade parts of the system while you can keep the rest working with old libraries, you can in fact deliver a working product every sprint.

But if you will develop an enterprise application that relies on a thick layer of relational databases and a complex business logic, it is rather difficult to vertically dissect the solution into shippable across-layer pieces that can be delivered incrementally.

In order for that to be possible, a good architecture effort is required in advance and possibly new architecture styles need to be used such as the one described in this white paper.

Microservices and Single Page Application

Keyhole Consultants (www.keyholesoftware.com) suggest that an architecture style based on Microservices-SPA shorten time-to-market for Scrum teams and enables agility and incremental delivery of working software.

So, in my opinion, Scurm alone is not enough for complex software intensive projects, it could be even dangerous! Among other things, you need to make good use of XP engineering practices to deliver quality products, and you need to build good architecture capability into your team to facilitate shipping every sprint which is very important for the success of Scrum practice as a whole.

Salam,

Read Full Post »

For many software engineers a typical day of code writing starts by googling code repositories for samples. Once a code sample is found, it goes through a sequence of copying, pasting and modifying to finally fit it into the software being developed! This is what is called Cut-And-Paste Anti-pattern.

For me such a practice makes developing software more like a craftsmanship! In essence, small scale with quality varying from one job to another. Should software reuse stay like this? I and many believe not!

Software development should be industrialized. It should adopt a production process where software assets are assembled in specific patterns to produce the final product. This is similar to what Henry Ford has done in Automotive Industry.

Having said that, reusing existing software parts is proven to be much more difficult than it is anticipated. For example we often find that the software asset intended for reuse is not 100% matching what we need and it will cost more if try to modify it, so we find ourselves writing it again from scratch,  “Not-invented-here syndrome“.

Over time, many attempts have been made to promote and facilitate reuse in software development. Some of these attempts were:

1-      Code libraries
2-      Code generators
3-      Objects
4-      Components
5-      Services
6-      Software Product Lines

From those, only Software Product Lines falls under the category of “Systematic Reuse Approach”. In Software Product Lines reuse is thought of and planned from the beginning, variability is scoped and software is built using domain specific kits that has a set of parts much similar to what your kid is doing with a LEGO kit.

With product lines we have two teams, an architecture team, whose responsibility is to create the software assets, and a product team whose responsibility is to use these assets to build a product for a specific customer.

SPL_Product Development

SPL Product Development, diagram courtesy of SEI, Carnegie Mellon University

Software Product Lines can be approached either:

1- Proactively: Where the core assets are developed first and In this case there will be high upfront investment.

2- Reactively: Where we start with one or more products and from these products we generate the product line core assets and then future products, this approach requires lower cost of entry.

3- Incrementally: Which is some way in between the first two approaches. In this approach we develop parts of the core asset then we develop one or more products and then develop parts of the rest of the core asset and then we develop more products …etc

According to case studies published by Software Engineering Institute (SEI), adopting Software Product Lines may yield up to 10x increase in productivity.

However, because product lines rely on good amount of architecture done ahead it poses a challenge for teams that apply Agile/Lean methods. In Agile the architecture emerges rather than extensively planned beforehand and while some see an inherent contradiction between the two methods, some researchers propose possible merge that would benefit from them both. And this is probably a topic that needs a separate post.

Salam,

Read Full Post »

Design Patterns, originally coming from Architecture, are the distilled wisdom… the ultimate objectiveness… the purified essence of… ok… ok… I will stop now…!
As impressed as I am with Design Patterns, it manages also to drag my attention not for the very deserving reasons sometimes… one incident when I was studying in the ITI and Monsieur Noel Plouzeau from IRISA gave us a 45 minutes design patterns introduction… the lecture was given in French and… no… I didn’t understand a thing! but I was thrilled by the examples he gave in SmallTalk and by integers being objects!
Another close encounter of the third kind with design patterns was recently when I bumped into a post by Grady Booch complementing a scholarly work on anti-patterns… again I wasn’t excited by the “anti-patterns” stuff as much as I was by the fact that the complemented Maged Alaasar is an Egyptian and ex ITWorxian same as moi 🙂

morning coffee design pattern

Best solution for waking up recurring problem: Morning Coffee Design Pattern

Read Full Post »

Assalamoalykom,

كل سنة و انتم طيبين
Eid Adha Mubarak, and may Allah bless you and your families in shaa’ Allah,

After some quality time with family during last two weeks Eid vacation, we are back again to business.

First thing was waiting for me was a project scope statement in Arabic! A challenging task  indeed, I will let you know in a coming post how did it go, for now and for this fresh cool morning here in Dammam here is a funny article that suites early morning coffee or if you wish tea with mint and milk :), enjoy.

An A-Z Guide to Being an Architect

Salam,

Read Full Post »

” The Architect – Hello, Neo.

Neo – Who are you?

The Architect – I am the Architect. I created the matrix. I’ve been waiting for you. You have many questions ..” from the Matrix Reloaded movie

 

Over the years I have met many people carrying the title of Solution Architect, IT Architect or similar, but I can’t seem to find a common understanding of what is the job responsibilities of the renowned Architect in IT.

My early perception of what is the role of the architect in the project team was that he is the person that has the answers for all difficult design questions like: What can the main components of the solution possibly be? How can we integrate them? How can we cater for quality requirements such as performance, availability etc ..?, What is the best design pattern to build a component that does x or y? Shall we use this or that technology for our presentation tier?,  In short, he is the most experienced developer or consultant… he has been there and he knows how things can be done to satisfy requirements and realize an efficient solution.

Later I found that Architect in IT is a multifaceted role, with multi talent and experience requirements, it actually manifests itself in different specialties such as: user experience architecture, software architecture, data architecture, infrastructure architecture, enterprise architecture and strategic architecture.

I have also met IT architects who have a specific technology preceding their names, I have worked once with an Adobe LiveCycle Technical Architect, also I have seen a job ad from a known regional software house requesting a .NET Software Architect so this an even more specialized type of architects.

In the same direction, different technology vendors also promote their own technology specific skills and certification for professional perusing architecture career path, both IBM and Microsoft are examples of that.

However, through my trial to clear the picture, I realized that a complete set of suggested skills for person to claim an IT Architect status is hard to be obtained purely by experience, a suggested taxonomy of skills can be found here, I came also to conclude that some sort of education is required, and I found that one of the most respected certification programs for Software and Enterprise Architecture is offered by Carnegie Mellon’s Software Engineering Institute, also software architecture training course is offered by Carnegie Mellon Executive and Professional Education as part of the Systems Engineering for Software Intensive Systems program.

So, that is it for now, please share with me your experience and thoughts,

Salam,

Read Full Post »