Release Management as a Competitive Advantage

“Delivery focussed”, “Getting the job done”, “Results driven”, “The proof is in the pudding” – we are all familiar with these phrases and in Information Technology it means getting the solutions into operations through effective Release Management, quickly.

In the increasingly competitive market, where digital is enabling rapid change, time to market is king. Translated into IT terms – you must get your solution into production before the competition does through an effective ability to do frequent releases. Doing frequent releases benefit teams as features can be validated earlier and bugs detected easily. The smaller iteration cycles provide flexibility, making adjustments to unforeseen scope changes easier and reducing the overall risk of change.

IT teams with well governed agile and robust release management practices have a significant competitive advantage. This advantage materialises through self-managed teams consisting of highly skilled technologist who collaborative work according to a team defined release management process, that continuously improves through constructive feedback loops and corrective actions.

The process of implementing such agile practices, can be challenging as building software becomes increasingly more complex due to factors such as technical debt, increasing legacy code, resource movements, globally distributed development teams, and the increasing number of platforms to be supported.

To realise this advantage, an organisation must first optimise its release management process and identify the most appropriate platform and release management tools.

Here are three well known trends that every technology team can use to optimise delivery:

1. Agile delivery practises – with automation at the core 

So you have adopted an agile delivery methodology and your re having daily scrum meetings – but you know that is not enough. Sprint planning as well as review and retrospection are all essential elements for a successful release, but in order to gain substantial and meaningful deliverables within the time constraints of agile iterations, you need to invest in automation.

An automation ability bring measurable benefits to the delivery team as it reduces the pressure on people in minimising human error and increasing overall productivity and delivery quality into your environment that shows in key metrics like team velocity. Another benefit automation introduces is consistent and repeatable process, enabling easily scalable teams while reducing errors and release times. Agile delivery practices (see “Executive Summary of 4 commonly used Agile Methodologies“) all embrace and promote the use of automation across the delivery lifecycle, especially in build, test and deployment automation. Proper automation support delivery teams in reducing overhead of time consuming repetitive tasks in configuration and testing so them can focus on the core of customer centric product/service development with quality build in. Also readHow to Innovate to stay Relevant“; “Agile Software Development – What Business Executives need to know” for further insight in Agile methodologies…

Example:

Code Repository (version Control) –> Automated Integration –> Automated Deployment of changes to Test Environments –> Platform & Environment Changes automated build into Testbed –> Automated Build Acceptance Tests –> Automated Release

When a software developer commits changes to the version control, these changes automatically get integrated with the rest of the modules. Integrated assembles are then automatically deployed to a test environment. If there are changes to the platform or the environment, the environment gets automatically built and deployed on test bed. Next, build acceptance tests are automatically kicked off, which would include capacity tests, performance, and reliability tests. Developers and/or leads are notified only when something fails. Therefore, the focus remains on core development and not just on other overhead activities. Of course, there will be some manual check points that the release management team will have to pass in order to trigger next the phase, but each activity within this deployment pipeline can be more or less automated. As your software passes all quality checkpoints, product version releases are automatically pushed to the release repository from which new versions can be pulled automatically by systems or downloaded by customers.

Technologies:

  • Build Automation:  Ant, Maven, Make
  • Continuous Integration: Jenkins, Cruise Control, Bamboo
  • Test Automation: Silk Test, EggPlant, Test Complete, Coded UI
  • Continuous Deployment: Jenkins, Bamboo, Prism

2. Cloud platforms and Virtualisation as development and test environments

Today, most software products are built to support multiple platforms, be it operating systems, application servers, databases, or Internet browsers. Software development teams need to test their products in all of these environments in-house prior to releasing them to the market.

This presents the challenge of creating all of these environments as well as maintaining them. These challenges increase in complexity as development and test teams become more geographically distributed. In these circumstances, the use of cloud platforms and virtualisation helps, especially as these platforms have recently been widely adopted in all industries.

Automation on cloud and virtualised platforms enables delivery teams to rapidly spin up/down environments optimising infrastructure utilisation aligned with demand while, similar to maintaining code and configuration version history for our products, also maintain the version history of all supported platforms. Automated cloud platforms and virtualisation introduces flexibility that optimises infrastructure utilisation and the delivery footprint as demand changes – bringing savings across the overall delivery life-cycle.

Example:

When a build and release engineer changes configurations for the target platform – the operating system, database, or application server settings – the whole platform can be built and a snapshot of it created and deployed to the relevant target platforms.

Virtualisation:The virtual machine (VM) is automatically provisioned from the snapshot of base operating system VM, appropriate configurations are deployed and the rest of the platform and application components are automatically deployed.

Cloud:Using a solution provider like Rackspace to deliver Infrastructure-as-a-Service (IaaS) and Platform as a Service (PaaS), new configurations can be introduced in a new Rackspace instance is produced, instantiated, and configured as a development and test environment. This is crucial for flexibility and productivity, as it takes minutes instead of weeks to adapt to configuration changes. With automation, the process becomes repeatable, quick, and streamlines communication across different teams within the Tech-hub.

3. Distributed version control systems

Distributed version control systems (DVCS), for example GIT, Perforce or Mercurial, introduces flexibility for teams to collaborate at the code level. The fundamental design principle behind DVCS is that each user keeps a self-contained repository with complete version history on one’s local computer. There is no need for a privileged master repository, although most teams designate one as a best practice. DVCS allow developers to work offline and commit changes locally.

As developers complete their changes for an assigned story or feature set, they push their changes to the central repository as a release candidate. DVCS offers a fundamentally new way to collaborate, as  developers can commit their changes frequently without disrupting the main codebase or trunk. This becomes useful when teams are exploring new ideas or experimenting as well as enabling rapid team scalability with reduced disruption.

DVCS is a powerful enabler for the team that utilise an agile-feature-based branching strategy. This encourages development teams to continue to work on their features (branches) as they get ready, having fully tested their changes locally, to load them into next release cycle. In this scenario, developers are able to work on and merge their feature branches to a local copy of the repository.After standard reviews and quality checks will the changes then be merged into the main repository.

To conclude

Adopting these three major trends in the delivery life-cycle enables a organisation to imbed proper release management as a strategic competitive advantage. Implementing these best practices will obviously require strategic planning and an investment of time in the early phases of your project or team maturity journey – this will reduce the organisational and change management efforts to get to market quicker.

Executive Summary of 4 commonly used Agile Methodologies

AGILE – What business executives need to know #2: Overview of 4 most commonly used Agile Methodologies

In the first article in this series we focussed on an overview of what Agile software development is and referred to the Agile SCRUM methodology to describe the agile principles.

Let’s recap – Wikipedia describes Agile Software Development as an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross functional teams and their customers / end users.  It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. For an overview see the first blog post…

Several agile delivery methodologies are in use for example: Adaptive Software Development (ASD); Agile Nodelling; Agile Unified Process (AUP); Disciplined Agile Delivery; Dynamic Systems Development Method (DSDM); Extreme Programming (XP); Feature-Driven Development (FDD); Lean Software Development (LEAN); Kanban; Rapid Application Development (RAD); Scrum; Scrumban.

This article covers a brief overview of the four most frequently used Agile Methodologies:

  • Scrum
  • Extreme Programming (XP)
  • Lean
  • Kanban

 

SCRUM

Using Scrum framework the project work is broken down into user stories (basic building blocks of agile projects – these are functional requirements explained in an in business context) which are collated in the backlog (work to be done). Stories, from the backlog, are grouped into sprints (development iteration) based on story functionality dependencies, priorities and resource capacity. The resource capacity is determined by the speed (velocity) at which the team can complete stories, which are categorised into levels of complexity and effort required to complete. Iterations are completed with fully functional deliverables for each story until all the needed stories are completed for functional solutions.

SCRUM

Scrum is based on three pillars:

  • Transparency – providing full visibility on the project progress and a clear understanding of project objectives to the project team but more importantly to the stakeholders responsible for the outcome of the project.
  • Inspection – Frequent and repetitive checks on project progress and milestones as work progresses towards the project goal. The focus of these inspections is to identify problems and differences from the project objectives as well as to identify if the objectives have changed.
  • Adaptation – Responding to the outcome of the inspections to adapt the project to realign in addressing problems and change in objectives.

Through the SCRUM methodology, four opportunities for Inspection and Adaptation are provided:

  • Sprint Retrospective
  • Daily Scrum meeting
  • Sprint review meeting
  • Sprint planning meeting

A Scrum team is made of a Product Owner, a Scrum Master and the Development Team.

Scrum activity can be summarised within the following events:

  • Sprint – a fixed time development iteration
  • Sprint Planning meetings
  • Daily Scrum meetings (Stand-Up meetings)
  • Sprint Review meetings
  • Sprint Retrospectives

 

XP – EXTREME PROGRAMMING

XP

Extreme Programming (XP) provides a set of technically rigorous, team-oriented practices such as Test Driven Development, Continuous Integration, and Pairing that empower teams to deliver high quality software, iteratively.

 

LEAN

LEAN

Lean grew from out of the Toyota manufacturing Production System (TPS). Some key elements of this methodology are:

  • Optimise the whole
  • Eliminate waste
  • Build quality in
  • Learn constantly
  • Deliver fast
  • Engage everybody
  • Keep improving

Lean five principles:

  1. Specify value from the customer’s point of view. Start by recognizing that only a small percentage of overall time, effort and resources in a organization actually adds value to the customer.
  2. Identify and map the value chain. This is the te entire set of activities across all part of the organization involved in delivering a product or service to the customer. Where possible eliminate the steps that do not create value
  3. Create flow – your product and service should flow to the customer without any interruptions, detours or waiting – delivering customer value.
  4. Respond to customer demand (also referred to as pull). Understand the demand and optimize the process to deliver to this demand – ensuring you deliver only what the customer wants and when they want it – just in time production.
  5. Pursue perfection – all the steps link together waste is identified – in layers as one waste rectification can expose another – and eliminated by changing / optimizing the process to ensure all assets add value to the customer.

 

KANBAN

Kanban is focussed the visual presentation and management of work on a kanban board to better balance the understanding of the volume of work with the available resources and the delivery workflow.

KANBAN

Six general work practices are exercised in kanban:

  • Visualisation
  • Limiting work in Progress (WIP)
  • Flow management
  • Making policies explicit
  • Using feedback loops to ensure customer and quality alignment
  • Collaborative & experimental evolution of process and solutions

By limiting WIP you are minimising waste through the elimination of multi tasking and context switching.

There is no prescription of the number of steps to follow but it should align with the natural evolution of the changes being made in resolving a problem or completing a specific peace of work.

It focuses on delivering to customer expectations and needs by promoting team collaboration including the customer.

 

A Pragmatic approach

These techniques together provide a powerful, compelling and effective software development approach that brings the needed flexibility / agility into the software development lifecycle.

Combining and borrowing components from different methodologies to find the optimum delivery method that will deliver to the needs of the organisation is key. Depending on the specific business needs/situation, these components are combined to optimise the design, development and deployment of the software.

Helpful references:

A good overview of different agile methodologies can be found on slideshare at https://www.slideshare.net/SmartBizVN/introduction-to-agile-and-lean-software-development.

 

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!

 

The 7 Deadly Sins Of Product Development

Guest Blog: Travis Jacobs via LinkedIn

1.   The Pregnant Woman Theory

If one woman can make a baby in 9 months, then 9 women can make a baby in 30 days.  Now you may laugh, but this is the most common problem in developing a new product. Throwing more resources at the problem and praying it goes away does not solve anything.

2.   Stepping Over A Stack Of $100 Bills To Pick Up A Penny

We can’t spend $10 on an off the shelf tool but we can spend $1,000 to develop our own, which doesn’t work and causes more problems than it solves.

Spending countless hours in useless meetings and then having a meeting to discuss why everything is overbudget and behind schedule.

3.   Champagne On A Beer Budget

Expecting everything for free and having It done yesterday. This is a very common occurrence especially when subcontractors are hired.

I want to hire an Engineer with 3 PhD’s, and 30 years of experience for minimum wage

4.   The Scalpel Is Only As Good As The Surgeon Who Uses It, Not All Tools Are Created Equally.

A Scalpel is a commodity, the surgeon who uses it to save your life is not.

Not all tools are created equally, choose the right tool for the right job, not just because that tool Is the cheapest and the “sales guy” said it would “work”.

5.   You Never Run Out Of Things That Go Wrong

There will always be an endless supply of challenges and things that go wrong. Pretending there aren’t any problems doesn’t make them go away.

6.   A Plan Is Just A List Of Stuff That Didn’t Happen & Everything Takes Longer, And Costs More Than You Planned

The battle plan is the first casualty of war, as soon as the first shot is fired the plan goes out the window. Likewise, when the first problem is encountered when developing a new product, the plan and the Gantt Chart go out the window.

7.   Good, Fast, Cheap… Pick Any Two

We never have time to do it right, but we always have time to do it over….. and over….. and over…..

I hear time and time again. Just get it done right now, we’ll fix it later. The problem is that later never comes, and the product is only “fixed” after a very expensive product recall. By then it is too late and significant market share has been lost as well as the reputation of the brand. Trying to save a few bucks in product development can cost millions in product recalls.

AGILE Software Development – What business executives need to know

AGILE Software Development – What business executives need to know

As a business executive how much do you really know about the Agile approach to software development? As the leaders within the company responsible for using technology innovation as an enabler to accelerate the business operations and improve the companies results, do you really understand your role and involvement in the technology development methodology used in your organisation? How can you direct the team if you do not understand the principals of the software development game?

All executives in businesses using an agile approach for software development must understand the basic principals, rules, practices and concepts of “Agile”. With an understanding of the methodology the software development team is following, a better understanding and appreciation of the team and their efforts are reached improving your ability to lead and direct the people involved across the business.

This series of Blog Posts provides an executive summary of the “Agile Software Development Approach” to get your tow in the water.

Agility is expected in modern software development and the customers assume that through appropriate planning, solutions are build with the ability to anticipate changes and to realign over time as requirements and needs are changing.

Agile comes from the Latin word ‘agere’ which means “to do” – it means the ability to progress and change direction quickly and effectively while remaining in full control.

Software development delivering products and solutions, usually come about through the same phases within the business:

  • A need – The business has a particular demand and/or requirement and need a new software product or changes and enhancements to existing software solutions to address this demand and deliver value to the client and/or customers.
  • Funds – Budgets are drawn up and the business secures the availability of funds required to deliver the new project
  • Project Acceptance – The business stakeholders approves the software development project and it is chartered.
  • A Plan – Project Planning and Management is the fist but also a continuous key exercise in any project.
  • Execution – Build it!
  • Acceptance and Go-Live – The business accepts the software as fit for purpose, addressing the need and it is released into production.
  • Support – The provision of operational and technical support to keep the new software working after deployment into production.

In addressing this business need, software technology development teams follow a typical cycle – The Software Development Cycle:

Requirements –> Design & Architecture –> Functional Specifications & Use Cases –> Acceptance Criteria –> Technical Specifications –> Code Engineering –> Testing –> Deploy –> User Acceptance –> Production –> Support –> Requirements for a new cycle

SWDev_Trad_Agile

In traditional software development, individual specialised groups of Business Analyst, Testers, Architects, Designers, Developers and Network Engineers completing each step by working through the full scope of the project before it is handed over to the next step. A lot of effort is spent in each of the steps and more time is spent in handing over documentation and knowledge from one step to the other until the project is done.

In agile software development, the entire project team, consisting of members from specialised groups, is responsible to complete small increments of working software that deliver value to the business. Collaboration, across the whole company and the end user, client or customer during the development of each increment, ensures the need is met. The full Software Development Lifecycle is followed in the development of each increment, which is concluded with a release of working software into production. Change is the only constant in today’s world, so the project planning is done one increment and release at a time starting with high-level functionality. More incremental releases are completed adding more detailed to the functionality until the full project scope has been completed or until the business is satisfied that the need has been addressed.

Agile project management is not meant to replace formal project management methodologies, but to compliment it.

Agile Software Development’s Prime Goal: High value, high quality software, delivered quickly and frequently!

Agile Manifesto

Agile is all about – expecting change through rapid feedback and interaction though-out the project; the ability to adapt and anticipate change events, delivering scalable components that address the stakeholder’s needs; parallel cycles of work delivery with good communication and progress feedback; keeping it simple assuming the lowest cost and simplest solution is the best; demonstrating the progress after each cycle and evaluate improvements to feedback into the next cycle.

Agile Framework

Being agile is all about being flexible and adaptable to continuous change. Agile project management can help to manage change consistently and effectively. It is all about thinking lean and making optimum use of resources as well as looking after the team though continuous interaction, coaching and mentoring to increase the performance.

Inception – Setting the project up for success

During inception all members of the team collaborate and define the outcomes of the project and what success looks like. The team grasps an understanding of the business requirements, meet the stakeholders, and compile a prioritized list of the functionality required broken down as “user stories” – later more on user stories. The high level solution design and underlining technical architecture are compiled followed by an estimating exercise defining the high-level effort required to deliver the project scope.

Iteration 0 – Preparation that enables the team to be productive from Iteration 1

In this iteration preparations of the team’s workspace, tools and infrastructure are completed.

Execution – The execution consists of a series releases that each consists of a series of time-boxed iterations – also called sprints – where the software increments are planned, built (coded and tested), deployed and demonstrated to the stakeholders.

image003

Closing – Was the business need met by this project delivery? Ensure everyone understands how the new changes introduced by the project will work in operations with appropriate handovers from the project team to the operational teams. The team does a retrospective to discuss the ‘Lessons Learned’ – What has worked well? What caused difficulties? What value and benefits were added? How accurate was the estimates? What should be done differently next time? These answers are an important feedback loop to continuous improvement.

Cycling through the iterations, the focus is on continuous improvement of the functionality, productivity and efficiency to optimize the use of funds and reduce waste. Through this constant cycle of adapting and learning, excellence becomes an reality.

Agile Methodologies: The next post give an executive overview of four of the most commonly used Agile Methodologies.

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!

How to choose a Tech Stack

WHITE PAPER – How to choose a Technology Stack

What is a Technology Stack?

A technology stack (Tech Stack) is a set of software code that is made up of modules used in software products and programming languages to build (develop/code) a software application.

The lower in a Tech Stack you go the closer you get to the hardware, for example a Operating System is the part of the tech stack that provide an interface between the computer user and the computer hardware, it communicates directly with the computer hardware. The higher you go in a Tech Stack the more specific and specialized the functionality becomes for example a DBMS (Database Management System) that provides the interface and platform to manipulate, store, manage and administrate data into databases.

Choosing a Primary Tech Stack usually involves the choice of the Operating System, programming languages, standard development libraries, frameworks, DBMS and a support community. The Primary Tech Stack will be used by most of the developers and software engineers in building the software product/application but several Secondary Tech Stacks may be used in support of the Primary Tech Stack to fulfill specific specialized requirements.

There are lots of different, competing technologies made up of different tech stacks, to build a website or software application with. A software application usually consist of the following main components: the Front End of the site/application (what the end users see on the screen and will be interacting with), the Admin Portal (that the application/program administrators or back office personal will use as an interface to administer and manage the application or site), the Middleware, Logical Layer or Application Layer (that performs all the ‘automatic’ actions and is the heart of the application doing all the calculations, processing and data manipulation), and the Database where all data used within the application or site is stored. Each of these components making up an application or website can be developed with a different software product or programming language but preferably within the same Tech Stack to reduce the complexity of supporting the application/site.

How do you choose a technology stack, what factors and key technical aspect should be considered to avoid the wrong choices?

When choosing your tech stack it is important to choose components that designed to easily integrate – the frontend technology must integrate with the admin, logic and database. The integration of the different application components is illustrated in the hand drawn diagram.

TechStack_Integration

The challenge today is choosing a Tech Stack, which supports current trends, and also future proofs your technology solution for the future. You can only focus your choice towards the Tech Stack that will be appropriate and the best fit for your business today and with that realize that the Tech Stack might change in the future as technology evolves – in other words there is no such thing as a fully future proof tech stack.

Considerations and Factors to keep in mind when choosing your Tech Stack

    • Development Lapse Time / Time to Market: How long will it take to develop an application in one tech stack vs the other. If the tech stack give you access to frameworks and platforms it will reduce the development lapse time and hence your time to market (in other word the application can be developed quicker).
    • Compatibility: Will the new technology work with exiting tools and software used within the business? Can you reuse previous developed software code in the new tech stack? Integrating the new tech stack into your existing environment, will it cause disruption or large quantities of rework of existing systems and infrastructure?
    • Cutting Edge: The more cutting edge the technology the more bumps their will be on the road ahead as the cutting edge still has some way to go to maturity and stability.
    • Productivity: If you already have a development team in-house, are they qualified to work with the tech stack? DO the developers have any issues with the new tech stack? What issues and pain did you and your development team have with the previous tech stack – are those addressed in the new?
    • Engineering Talent Availability: Is the right people available to support the tech stack you intend to use? The right people will be across the board including, architects, tech leads, senior developers, developers, database developers / administrators, etc. Will it be easy to find these people? This is linked to the popularity of the tech stack – the more popular the more talent will be available. Where (in which location) will you need the talent – what is the availability of the talent in your preferred location, the location where you want to build you in-house and offshore teams?
    • Recruitment and Retention: How ill you recruit the talent for the tech stack? Will what you have to offer (salary, working environment, training, personal growth, business prospects and growth, etc.) be attractive to the market of professional knowledge workers (technologist)? Make sure that can recruit and retain your technology staff to support your tech stack, otherwise it might be an expensive choice.
    • Expertise: What level of expertise on the new tech stack do you have within your (in-house or outsourced, on-shore, near-shore or off-shore). Make sure that you have staff that are well experienced with the tech stack and ensure that they understand your business drivers and your requirements. Ensure that within your team you enough experts (at the right levels i.e. Tech Leads & Snr Developers) that thoroughly understand the tech stack intrinsically.
    • Maintenance & Support: Different programming languages promote different style for example Object Oriented (OO), Strongly Type (Functional) and Dynamic styles. As the complexity and the magnitude of the technology solution increase and/or the team that develop the solution is large then OO style programming languages bring a lot of value. Strongly typed languages and their frameworks like C++, C#, Java and Scala support better tools while Dynamic one like PHP, Pyhton, Ruby, Javascript take less development time. The trends based on the above is that strongly type OO languages are mainly used in enterprise solutions where code base size, team size and maintenance matters. Another factor to consider is the standards and methodology followed by developers in writing the code. Some software development methodologies introduce very robust quality assurance and code validation that delivers a very superior, bug free solutions that are easier to support. A well-written technology solution is also adequately documented to ensure maintainability and supportability. Other factors like team knowledge, expertise and the availability of resources/talent (as mentioned in other points in this section) to form a solution support team must also be kept in the equation.
    • Scalable: Scalability refers to the ability of a solution to easily adapt to service more users, process more data within a specific timeframe without increasing the overall software and development cost. Hardware is mostly directly related to the scalability for example the more the solution scale the more hardware might be needed to support the technology solution. Scaling can take place horizontally – that is adding more hardware (servers) to the overall solution or vertically which increases the ability to process more data and/or request/users on a particular server. Will the tech stack scale to meet your requirements in performance? How easy is it to scale the solution horizontally? How does the tech stack compare with others in vertical scaling? If you know your solution will be receiving high traffic (lots of users) or will be processing loads of data the choice of your tech stack becomes very important. The difference in the scalability of two tech stack can be seen in timing and compairing the systems’ response in processing the same about of user requests or data for example:
      • Ruby is 30 x slower than C
      • PHP is only 8 x slower than C
      • Java is a mere 2 x slower than C
    • Community: How strong is the community for your selected tech stack? A strong community is a key factor is selecting a tech stack as an active and devoted community ensures the following:
      • Availability of Documentation
      • Fast response to bugs, issues and problems. Response and support to resolution of issues that might appear to be specific to your solution
      • Availability of issue and problem solutions and the source code to copy/paste speeds up the resolution
      • Continuous updating of the basic framework, increasing the availability modules and libraries, producing new releases that results in a more stable tech stack
      • Availability of resources/talent understanding the tech stack
    • Quality of Tools: Ensure the tech stack provide adequate tools to the development and support teams to use for example IDEs (Integrated Development Environment), Debuggers, Build Tools, etc. Adequate tools will ensure you have an empowered and engaged development team that can get the job done.
    • Licensing: Tech stacks are licensed differently – either Open Source or Commercial licensing applies. Open Source tech stack has grown tremendously over the past view years. Statistics show that on the internet, more open source tech stack driven solutions (solutions based on the LAMP stack consisting of Linux, Apache, MySQL and PHP) are present than commercial tech stack based solutions like Microsoft consisting of Windows server, IIS, SQL Server and .NET. When deciding on a tech stack it is important to understand the different licensing types and the associated cost to the license to use the software not just for development but commercially in the mainstream production environments of your business. Open Source licenses are usually cheaper than commercial licenses. Make sure that you understand the type of license the tech stack components are under and that you have the associated budget.
    • Hardware Resource Hungry: What level (quantity and specification) of hardware will the tech stack require to run your application effectively according to expectations and requirements? Some tech stacks require several different servers to run a single application dependent on the complexity. This should be taken into consideration especially in conjunction with the budget constraints. Tech stack and Hardware requirements are dependent on the performance and uptime requirements of the operational technology solution. A solution that needs to be up and running every second of the every day and/or are procession large volumes of data in the shortest possible time, will have a higher dependency on the hardware with infrastructure design incorporating the resilience against hardware and connectivity failures. Hardware is not directly dependent on the tech stack for redundancy but some tech stacks are better suited for high availability with build in capabilities, than others.
    • Popularity: See point on Talent Availability and Documentation
    • Future Proof: This is a relative concept because none of us have a crystal ball to gage exactly what the future will hold in order to choose our tech stack accordingly. How long into the future are you looking to proof your application, recognizing that technology is rapidly changing and no single tech stack has ever been and will ever be available and around for ever. Even tech stacks like Microsoft that has been around for twenty plus years has changed within and the older tech stacks from Microsoft are absolute while newer options are introduced every two to three years – sometimes without appropriate backwards compatibility. Your tech stack must be agile (adapt to change), backwards compatible, scalable (to accommodate your business and market growth), from a reputable supplier (a supplier that is credit worthy and likely to be around for the future) and popular. Popularity is very important and the community following, embracing and developing a tech stack will ensure the availability of talent and support resources to ensure your application build in a particular tech stack can be supported long into the future.
    • Documentation: Are the appropriate documentation available for the tech stack to completely enable your team to utilize the power of the tech stack? Documentation includes printed manuals, internet information resources, sample code, module and libraries, community forums where issues and problems are discussed and resolved with solution code that can easily be copied/pasted.
    • Maturity/Stability: What is the latest released version of the tech stack. A mature tech stack with release versions will be much more stable than a version 1 release, for example.
  • Company Constraints: Is your tech stack choice affected by certain constraint within your business i.e. if you are looking to develop a native mobile application for iPhone or iPad who have no other choice but Objective C for your programming language. Do you have access to a DevOps team (operations team ensuring the software development and operational infrastructure seamlessly integrate)? If not you might want to consider a PaaS option and use the stack it supports. Other constraints can be: legal requirements like PCI DSS (Credit Card and Personal Information security legislation and requirements), budget and operational costs.

 

What are the popular choices in Tech Stacks?

Operating Systems
·       Microsoft Windows

·       Apple OS X

·       Linux

·       Mobile

·       iOS

·       Android

 

Programming Language Associated Web Framework
Java ·       Spring/Hibernate

·       Struts

·       Tapestry

·       Play! (Scala)

Javascript ·       JQuery

·       Sencha

·       YUI

·       Dojo

PHP ·       CodeIgniter

·       Zend

·       Cake

·       Symfony

Python ·       Django

·       web2py

·       TurboGears

·       Zope

Ruby ·       Rails

·       Sinatra

C# ·       ASP.NET

 

Web/Application Servers
·       Apache

·       Tomcat

·       Netty

·       Ngnix

·       Unicorn

·       Passenger

·       IIS

·       Microsoft Windows

 

Databases
·       Microsoft SQL Server

·       MySQL

·       Postgres

·       Oracle

 

Cloud PaaS (Platform as a Service)
·       Heroku

·       CloudFoundry

·       Microsoft Azure

·       Redhat Openshift

·       EngineYard

 

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!

 

Source & Reference List:

The Art of IT Effort Estimation

Why Estimate at all?

Estimation is an essential part of any project methodology. Estimation is used for a number of purposes:

  • To justify the project enabling the costs to be compared with the anticipated benefits and to enable informed comparisons to be made between different technical or functional options.
  • To enforce the discipline needed to make the project succeed.
  • To secure the resources required to successfully deliver the project.
  • To ensure that the support impact of the project is fully understood.
  • To inform and improve the software development process.

What is estimation and why is it so important

Projects are planned and managed within scope, time, and cost constraints. These constraints are referred to as the Project Management Triangle.  Each side represents a constraint.  One side of the triangle cannot be changed without impacting the others. The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project’s end result.

These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.

PM 3 Constraints

What are the challenges

  • Lack of communication between…a…b…c
  • Lack of training in basic knowledge and techniques of estimation
  • Inability to do estimations based on – cost – time – scope
  • Project failure through time over runs and faulty estimation

Where are we going wrong?

  • Every day, project managers and business leaders make decisions based on estimates of the dynamics of the project management triangle.
  • Since each decision can determine whether a project succeeds or fails, accurate estimates are critical.
  • Projects launched without a rigorous initial estimate are five times more probable of experiencing delays and cancellations.
  • Even projects with sound initial estimates are doomed if they are not guided by informed decisions within the constraints of the triangle.
  • If you are working under a fixed budget (cost constraint), then an inaccurate estimate of the number of product features you can produce (scope) within a fixed period of time (schedule) will doom your project.
  • Inaccurate estimates across your projects de-optimize your portfolio.
  • Estimates are always questioned when estimates are given with knowledge – no estimation template is being used

How can we improve?

  1.  Outsource the project estimation function to an outside qualified consultant for each project to be able to gain viable and realistic project estimations that can be achieved.
  2.  Education of in-house project managers and technical leads so that we are able to collectively able to provide clear methodologies on how to estimate accurately.

This can be done through an onsite workshop/course  – onsite is cost effective as company will pay one block fee for the attendees instead of delegates going offsite and attending a workshop where individual fees are applicable.

My personal recommendation is option B – as this option will allow us to retain skills in house to be able to produce accurate estimates

What are the long term benefits

Well crafted estimate creates many benefits:

  • alignment between business objectives and technical estimates
  • more informed business decision making
  • reliable project delivery dates
  • improved communication between management and the project team
  • controlled project costs, and
  • satisfied customers

Conclusion

The UK is facing ever tightening economic restraints. This means the quality of work is now, more than ever, of the utmost importance. To stay competitive in a shrinking marketplace, this company cannot afford to get a reputation in the industry for non-performance and bringing in projects over budget and outside estimated time frames. Credibility is the basis on which we build our reputation. In the eyes of clients credibility = successful projects. For us the success of all projects rest on the correct and precise estimation from the start of a project based on best practices, realistic expectations and transparency.

 

Reporting Services Pioneer

Microsoft Tech-Net Mag 10.2004

Renier Botha, Director and GM (General Manager) at CFS (Customer Feedback Systems – now Customer First Solutions), talks to Microsoft TechNet magazine about the pioneering work done using Microsoft SQL 2000 Reporting Services, making CFS the first company to go into production with their “Service Tracka” product using the new Reporting platform from Microsoft.

The first version of the “Service Tracka Reporting Suite”, developed on the Beta version of Microsoft’s Reporting Platform utilising SQL Reporting Services, DTS (Data Transformation Services), OLAP (Analysis Services) and SQL2000 Database, enabled CFS to crunch through a large amounts of data collated from accross the world and deliver thousands of daily scheduled reports to clients helping them to measure customer satisfaction as part of the NPS (Net Promoter Score) KPI (Key Performance Indicator).

Read the full article here… Microsoft Tech-Net Mag 10.2004