Thursday, December 19, 2013

what exactly business strategy is about

The first and important point of this post is:

“Every business needs a strategy in order to succeed!”

Does it sound obvious? Yes, I think to most of us… but there are still businesses operating without a realistic or sustainable strategy. Or they operate with a flawed strategy.

Sometimes the business strategy is reduced just to one piece of a complex puzzle. For example to Branding.

The right and clear strategy helps the companies to take the business where it should develop, and makes it possible to evaluate along the way, so changes can be made if needed.

So what I understand by “Business Strategy”?
I am considering a Business Strategy in three categories, what makes it easier to me:
  1. Formulation
  2. Implementation
  3. Evaluation

It does not make sense to jump into strategy in the middle; it has to be put together piece by piece.

Formulation is the first stage of Business Strategy. Sitting down and reviewing things about the current business and the development made so far. After I know the current situation, I can start to create the plans where I would like to be, and how long it will take me to get there.
At the end of this stage there is a plan for the company to achieve these stated goals.

After the first phase and with existing plan or strategy we can start with the Implementation of our strategy. We have to set aside money for the plan, choose people to be in charge of the plan, and decide exactly how to put the plan into place.

Often are also new training and organizing necessary, and the integration into the already existing processes of company.

Evaluation, is something executed on an ongoing basis throughout the duration of the particular strategy put into place. Depending on how well the plan is working, and is it bringing business closer to your stated goals, the things need to be modified in order to work better. The environment can change during this time, so that a further readjustment of the plan is necessary.

Tuesday, December 10, 2013

Scale Up Your Company

I think it is more than clear and obvious - unavoidable: In order to grow your company it has to change what it's doing now.

Every change means taking risks, but some changes are more risky than others. In situation you have a new product you would like to place in the market.

So you need to create a new message which will get your prospective customers to do something you want. Sort of campaign.

The business owner has to invest into the new message and for getting it out there before it could be known if it will have the desired impact. That is a huge risk right? At least I thought so...

But this is not entirely true.

You can limit your investment and don't pay for a full campaign before you know if it will be really successful.

How should it be possible?

Just split your campain process to three process steps:

-> pilot -> perfect -> scaling-up

This technique can be used for developing new products or services.

Pilot them by testing the concept and then the prototype with a few potential customers. Use their feedback as a retrospective to modify and evaluate your original idea.

After roll out it locally. In case of any unforeseen problems, you can perfect the new product/service by either shipping them back or getting support people out to customers relatively quickly and inexpensively.

Scale up by going for a national or international launch only after managing the risks by taking the first 2 steps.

And why am I writing about it? Because I have to face again and again situations where “pilot, perfect and scale up” process should have been used and wasn’t.

Tuesday, December 3, 2013

Continuous Delivery - software-architectural topics

In my last post about Continuous Delivery was the focus on the delivery process. However in this post we will concentrate on the software and the necessary architectural requirements.

So the central question is, how to deliver new functionality as a software many times during a day without adverse effects. How is it possible that companies like Facebook despite major projects with hundreds of developers can manage this?

The first step in the praxis should be the system redesign from a monolithic application towards to split into small pieces (functions, components).
The components are separated and the communication is possible just via a clear API, like for example REST.

The second step would be the redesign of the underlying database
Encapsulating the access logic in an interface promotes a service oriented design. A distinction is made between an Application Database, belonging to one application, and Integration Database, shared by different applications and systems.

Avoid Server-side Session State
If short-time information are stored in a local cache of the server then we are talking about Server-side Session State and as such there are the particular instance fails the session is gone. For example during a deployment of new software version to this server instance.
Stateless services enable  a downtime-free deployments.

Keep backward Compatibility
This point is not so easy and it is very complicated to guaranty the compatibility after each modification of the system. Actually this means that the new functionality is co-exists with the old one.

Design for Failure
No system has got 100 percent availability. More important for the enduser is the impact of not functioning component. If one specific function fails, it should not cause the failure of the whole system. 
This is very crucial for continuous delivery concept, otherwise the risk of failure and its impact would be enormous.

Schema-less Database
Changes on the structure of database or its migration are in most of the time very complicated and risky.  The clear advantage is coming with NoSQL databases, or with migration running inside of the application and not in separated database migration scripts. Such scripts last too long and the migration would be not possible in the real-time.

Overall, the goal should be to reach the "Shared-Nothing" Architecture.  This architecture is defined through no direct references between two or many systems which enables a horizontal scalability and release deployment without down-time.