Third World Agility

Strongly Motivated to Succeed.

When considering agility in terms of creating products, motivation is one very important aspect of being able to work on something effectively. Getting motivated to start working on something is easy, but keeping yourself motivated to succeed is another issue all together. Most of the times, getting motivated to start is easier than keeping at it.

Have you ever heard the phrase "keep walking"? It might be a rip-off of a liquor ad, but that's something easier said than done for a few reasons:

• Starting to walk takes effort. The effort involved in motivating yourself to walk is usually trivial, but nonetheless exists. It's usually easier to start walking if you already have directions, and when you have a clear path to where you're going. Getting started usually is a very exciting time, when the anticipation of the outcome is the highest.

• The first challenge is the most crucial. Let's say you're already walking, and you suddenly realize that the path you've taken gets a little steeper than the first few steps. You weren't able to anticipate that it would be this hard, and the response to the first challenge is the best indicator of the quality of the people involved. When you get the first challenge done with, it will define the whole mood of the journey.

• Delays induce anxiety, and "are we there yet?" becomes annoying the first few hundred times. We know that patience is a virtue, and not all people are patient. Yet the driven are also people, and annoying them doesn't get you too far. Perhaps a better question would be "where are we now, and where are we going?" rather than just plain "are we there yet?".

• Being there is never enough -- and be prepared to be never there. Directions can change over the course of time, especially if the journey has already taken a while. Maybe instead of the highest peak of Mt. Everest, you settle for the closest you can ever get because you're all losing fingers the higher up you go. Or in the case of software, all the features earlier requested seem to be too much for what is required, and the list is cut short -- or worse, the original features are removed and the project completely changes direction.

The challenge for IT companies (managers, supervisors, developers, and decision makers) is how to keep the work force motivated so that you achieve the goals already set. The even greater challenge is adapting to the change induced by a lot of external forces while contending with available resources and targets.

Just like altruism, being driven is something in-born to a person (or developed over a period of time) but it can be a quality which an IT company can adopt to not only project an image of passion and committment, but also as a means of motivating the work force to become productive as a part of the company.

The ends justify the means -- but when the ends change, the means change. When walking, keep an eye on the destination and the other on the path.

Altruism is unselfish concern for the needs or interests of others, providing gratification vicariously or from their responses. -- gotten from here . There are more definitions for altruism here.

When you're in the business of helping people, you should take pride in your ability to help. You should also take their interest and make it your own -- so that their success becomes your success. The fact that you're getting paid to do that is a big bonus. And when you focus on delivering your service to enable your customer rather than focusing on getting paid, then your work becomes more about delivery than revenue.

The problem with being fixated on revenue (too much) is that you lose sight of the precursor which is delivery. When you deliver and are reliable, you (should) get paid. However, the satisfaction you gain from delivery should be the driving force for revenue. The point in travelling is not the destination, but the journey.

When your business requires that you deliver a product on time and within specifications, you should focus on that instead of (just) the revenue you generate. This sounds like a foolish ploy to go broke fast, but look at it this way: when your work is your advertisement, it's better than hype of hot air. No matter how much advertisement and marketing you do, it's no substitute to good service and reliable delivery.

How about value add? When you have great service and reliability, value add is now hinged on the relationship with the customer. If you can build lasting relationships with your customers by making them feel important and by keeping their interest in mind, then that should be the value add of your business. I'm not talking about just being friends with your customers, it's something else -- it's being a good friend to them that matters more.

Altruism is not something you can practice, because it's usually built into a person -- however if you're in charge of making decisions for a business, then you have the power to give your enterprise a personality. An altruistic personality fits well for businesses that make stuff that their customers use to build better products.

Is your IT company altruistic enough?

It's not what makes me happy... It's what makes you happy.

As a consultant, one of my goals is to empower clients to become self-sufficient, successful, and effective. Empowerment is one of the key aspects of modern businesses -- it is what allows consultants to become successful with the client, and an enterprise to become successful with their customers. This post is about how an enterprise can empower the customer to make them more productive with them and their product/service than without them.

Being indispensable to your customer is a good strategy. Being indispensably helpful is yet another. Empowering and Enabling your customer is yet even better. This is what makes the largest IT companies in the world the most successful -- these companies don't just sell software, they allow you to do more things with their products/services. This works not only for IT companies, but also more traditional businesses: if you sell something that allows the customer to become happy, empowered, and productive, then their success is translated to your success.

Throughout the next few days/weeks, I will tackle some aspects of Agile Development which will emphasize on the empowerment of project stakeholders, especially software developers and managers.

This is a considerably broad and tricky topic, and I hope I can do justice to the different advice that other people before me have already suggested.

Knowledge is Power. Height is Might. Knowing more allows you to see what you don't know yet. Growing more allows you to see how much bigger you can grow. But knowing enough and staying high enough breeds stagnation, and there is no power without change. Only through progressive change can results be found and measurements taken.

When building roads, engineers take a lot of things in consideration: expected volume of traffic, expected load on the roads, expected length of the roads, and special terrain conditions. Much like software that spans a lot of domains -- like enterprise systems -- a solution shoud be chosen based on the expected volume of transactions, how much processing will need to be done, how much data will have to be dealt with, and special domain requirements.

For systems that are meant to serve a lot of users at any given time, and perform as robustly as possible, and minimize down time certain architectures fit the bill better than others. Let me enumerate some of these architectures that in a lot of ways, are like Interstate Highways -- high reliability, high scalability, and robust.

Three-Tier Web Applications

There are a lot of these enterprise solutions that use this architecture where the front end of the application (usually a web site, or a special client application) interfaces a middle tier holding the "business logic", and the back end usually a database management system. This architecture proves to be robust and scalable since each of the three tiers can scale as necessary -- based on demand and actual circumstances. These systems are managable too, since the different roles of the solutions are made self-contained and de-coupled from each other to a certain extent.

However, this architecture proves to be single minded -- or a better term would be domain directed. When you create web applications that use the three tier approach, usually the functionality required is programmed in the middle tier. This means you have a bungalow in between two bungalows tied together with different connectors.

This solution is attractive for clearly targeted applications such as e-commerce systems, online community sites, and content management systems. They make sense because they're essentially a three part house (or a three layered house), or a two lane highway which expands to the sides only.

Distributed Systems

A distributed application or distributed system is one where the functionality of the solution can be located in different non-dependent locations/systems where each other the functionalities may or may not be related. This allows the solution to scale well as new functionality is required, and a well-designed system for service discovery and registration is used to coordinate these different services as well as made available to different users of the system. Distributed application design allows developers to access a central service brokerage system to which service providers (which may replicate the services of each other, or provide completely different services) can register.

The main down-fall or issue in this system is the central brokerage system which becomes a crucial point of failure for the whole design. This may be side-stepped or circumvented by directly accessing the service provider in an end-to-end fashion, however this approach will make clients completely dependent on a single service provider. This end-to-end coupling is a potential point of failure which is not a solution to the original problem.

This system however is most effective in non-mission critical applications where flexibility is valued more than reliability, and maintenance is covered by different domains of influence. This system can be likened to a system of streets and side streets where a common avenue runs through all possible connections. In these systems, the avenue may be circumvented but ultimately they serve a purpose of keeping the system of streets connected.

The Hybrid

Combining the best of both the Three-Tier Web Application and the distributed system allows users to enjoy the flexibility of the distributed design, and the robustness of the three-tier design. This basically works by making the tiers distributed systems -- allowing for flexible service usage and registration -- at the same time clearly delineating an interface between the tiers in the original design.

Another hybrid of this system is making the service providers in a distributed system part of a three-tier web application architecture. This means each service provider is essentially a front end in a three-tier system where the middle tier can scale to the demands of the front end. This also allows the service providers to replicate the front end such that it can serve more users at any given time.

Only by determining the requirements in terms of flexibility, maintainability, reliability, and robustness will the right architecture for systems be determined. These decisions are usually made before hand, especially when the requirements are being determined. Making the design decisions at the start also allows the developers to gauge how much work will be done, and thus how much time it will take to come up with the system.

Knowing what to do first allows you to decide how to do it. What you need will dictate what you should be done, and what you know or don't know will dictate how you'll do it.

A house with one story and divisions to create rooms is called a Bungalow. When you hear the term Bungalow, you get the idea that it's a house with one story. Here is a listing of the many definitions for a Bungalow.

There are a lot of solutions where a single self-contained application can do the trick. There are also a lot of solutions where there may be other available applications, but unfortunately a lot of the software written in the 90's were meant to stand alone and are meant to be self-contained. They didn't require a lot of other things to operate, and don't really care whether there are any other applications installed in the computer.

Bungalows have a property which can aptly be seen in a lot of these tools: they are small. Back in the early days of personal (and enterprise) computer systems everybody had limited resources -- so the applications needed to be small and self contained. Usually, these applications only do small simple things -- and usually don't require a lot of other applications to perform its duty/purpose.

A Bungalow also has all the rooms in one floor -- so you have only one layer. You have everything you need in one floor, so you don't need to go too far to get something. This is true for self-contained applications where all the functions they need are mostly found in a single binary file (sometimes some services are supplied by external sources like the operating system, or a software library -- think utilities like water, sewer systems, gas pipes, etc.)

So what's wrong with a Bungalow?

It doesn't scale with the people using it. You can only house so much people comfortably in one bungalow. And usually, as the bungalow grows, it's harder to maintain. Not to mention that you can't really grow a bungalow too much, because you're limited by the real estate.

In the same light, standalone applications are like Bungalows, in that they don't scale too well, and as they grow larger they get harder and harder to maintain. Monolithic solutions where all the units of functionality are confined in one application are limited by the computer resources on which the single application is running in.

When does a Bungalow make sense?

A Bungalow makes sense for a low budget small family. They do the job of housing the people, and usually come at a considerably cheaper price tag compared to other house types. It's easy to build, and can last a long time (when built right).

Much like monolithic applications, a low budget firm who doesn't need a scalable solution for a particular problem is a very attractive solution. Keeping things small and simple (and cheap) is just right, especially if they don't expect the requirements to change too much (or even at all, how rarely the case may be). Monolithic software is also easy to build, and can last a long time when built right.

So What's the Point?

When you need a quick solution to a small not so recurring problem (like finding out the square root of a number), you can use small effective tools that come cheap and are functional (like a calculator). However, when you start needing the roots of a transcendental exponential polar system of non-linear equations in N dimensions, then you might not be able to solve that so easily with a simple calculator -- especially if you do it more than once, and need to do it quickly many number of times.

The trick here is recognizing the problem, and the scale of which you're going to be solving these problems. Simple problems usually need simple solutions. If you find a complex problem and see a simple solution, then you're in luck -- otherwise, prepare to come up with a complex solution nonetheless.

Complexity defines size.

When do you determine the architecture of your whole system? Do you go with an architecture you've already seen and used, or one that you know will be most effective for your solution? Do you go with the best and feature full, or the fastest and easiest to deploy?

All week I will be writing about making architectural decisions -- when to choose robust feature full solutions, and when to use the light, quick and "dirty" solutions. It's all in the light of making design decisions when you're already working on the user stories.

So when do you choose the architecture?

In Agile settings, you choose the architecture for the solution everytime you need to -- which translates to, almost everytime you write code. When talking about architecture, the discussion covers the hardware and software components of the whole solution -- and how the system should look like from afar. That is, from a higher level -- higher than the code.

This seems like a simple task, but it really isn't all that simple -- there are a lot of things that need to be considered: budget, timeline, problem domain, scale, core competencies, among many other things. It also assumes that you have a host of architectures already in mind -- otherwise, that's yet another discussion.

In the next few days, I will be outlining criteria I use to determine which architecture (infrastructure wise, containing both software and hardware solutions) to deploy in different settings. I will be providing hints and insights into different domains that I've had the privilege in working with.

A good design looks good and gets better when it's actually built. A bad design just breaks everything. So design it as good as you can, and hope it doesn't break too much in the end.