Industrial revolution changed the way we live for ever. The latest trends in application development will result in the same thing.
We have come a long way in software and application platforms. Procedural to object orient to SOA. RDBMS to NO-SQL to big data, waterfall to iterative to agile scrum and many others.
Time it takes to develop an application is always a concern.
How much time will it take to take that data onto the screen as information?
Information on screen is what we need today.
Big Data and Need for More Apps, Sooner
The volumes of data are massive, that lead to big data technologies. And it is predicted that within the digital universe the data volume to double every 18 months. This makes it challenging to keep up with application development. Because, applications, in simple terms, are about bringing data to screen as information. Hence, building applications need to keep phase with
- The growth of data
- The growth of demand to consume those data
The problem is not the volume of data, rather the volume of apps we want on top of them.
So developing applications need to be done faster in much more productive and efficient manner, because
- There are many apps to be developed
- Given the wide range of users, platforms and devices, need multiple perspectives, thus plethora of apps
- Time to market or time to go into production matters, else the value of the IT systems will fall short of expectations (and those who master the technique would win)
Developers, Agility and Applications Assembly
The IT industry uses agile methodologies to develop applications that meet stakeholder expectations today. While the agile techniques help us to get over the traditional process bottlenecks, the tools and techniques provide the edge to the developers when it comes to be agile.
The most frequent question that the dev team gets: Are we there yet?
Developers divide and conquer the problem space. And they need to collaborate and communicate around the design. For example the component API touch points, data formats, data representations and presentations are some areas that the development team peers have to communicate and collaborate on. In this exercise, some developers will have to use others components APIs. And some will have to expose what is developed by them to be consumed by others as components/APIs. So, some developers are testers of others, but the point is the whole team is developing in parallel, because everyone wans that working now.
So governance matters. It starts with simple things such as versioning. Those developing the precedence components in terms of dependency will have to be ahead of the version curve. Those who use those components will have to be lagging behind the version curve. Those dealing with the UI, will have to deal with the lowest version numbers to start with.
Upstream and downstream dependency management support needs to be a key focus of your app development governance tooling.
When the system is dynamic and being developed in parallel, picking up form stable versions of dependencies will be the key for those using the components/APIs to ensure that they can continue with productive work, without hitting impediments. However, waiting for stable cannot be done for weeks. Dependencies need to come in days, if not in hours.
Talking about making working pieces of the application being made available in hours, the build, the integration and the developers ability to test on a real setup then and there matters a great deal. This is where the pre-setup development cloud with PaaS components comes into play. Each developer can developer test what they are working on and verify against the real integration points, before handing them over to the others to be used.
Test environment non-availability is a common “excuse” to not doing meaningful developer testing.
Talking about handover, automatic builds, and automatic deployment help verification process to get agile. And when the developer is happy about the quality of the component of the app, he or she can push that to the next state via governance life cycle. So when a version in development goes into QA, it is not only the people who are going to test that will be interested in it. But also those who want to consume it, in their respective consumption dependency downstream. They can either try it sooner on the QA endpoint, or wait till it hits staging, if they want QA verification. It is a developer decision, which could be guided and governed by development best practices and policies.
The collaboration model needs to encourage developers to re-use. This not only saves time but also solves the NIH syndrome as a whole. So the governance tooling needs to help discover what is there already and the state of those available. This ensures the focused effort of the development team to work on the most needed areas of the applications and not keep re-inventing the same.
If you want your apps fast, facilitate re-use through discovery.
Once the application platform gets to some stage within an enterprise, the visualization layer for end users takes the center stage. Sometimes, the new applications will only be about visualization. Also, the most dynamic layer of applications is the visualization layer. The same data or APIs will be consumed in different combinations to represent different perspectives. So the application will be all about consumption of APIs or data sources, their data representations and how those data are presented as information. The tuning to these applications will be numerous, to suite the stakeholder expectations meaning we have to do rapid changes to keep the applications maintained. Also, there will be the need to implement multitudes of applications, leading to the need to maintain that multitude. Applications now in production cannot be taken offline at will, but still, those changes implemented by developers need to be seamlessly deployed into production.
Need for Quality Assurance on the Assembly Line
While test driven development and developer testing and automated tests can help verify what the developer has done, by the developers on their own, when in production, QA approval is a norm.
Now, you are hit with the dilemma of extreme quality vs. business agility. Will formal QA take too long and will that hinder our agility? Let’s keep aside agility for a while. No matter what, quality matters, and cannot be compromised. And there is nothing like a second pair of QA eyes to look for quality. Some say, the developers can never think like the way QA thinks, they are a different breed. So we need formal QA. Now, let’s see how to make it agile. There are so many agile testing principles. But again the tools and techniques matter.
Setups take more time than actual testing.
If you are a QA engineer, or even a developer at that, you will know, testing something to verify quality takes time, because, it takes time to setup the environments. The configurations, the parameters, the artifacts by the developers, they all need to be synched up. And so often, human errors in copying files, or editing configuration files in the setup can waste days, if not weeks. In fact, very often, that initial setup takes lot of time. So what is the solution? The pre-setup PaaS based QA cloud will have it all setup to go. No setup cycles wasted and so no room for human error.
Verify the apps user stories and business logic, NOT the setup!
So the QA team can now focus on integration and system testing aspects. And they can focus on their core job of QA and verification of application user stories, data integrity, information consistency and nonfunctional requirements such as performance, security and usability. They will not waste any time preparing for QA.
Also, like in the case of developers, the members in QA team, working on the various components or aspects of the same applications, can collaborate with each other, using the governance model in the system. For e.g. they can also use the same versioning and dependency precedence model and take dependency to those already in staging or in production when verifying what they are testing, without having to wait for others.
DevOps and Daily Production Rollouts
Time to market an application or the time it take to take the application from cradle to peak of life (that is to be in production) is quite sensitive. There are well defined tools and practices such as Puppet/Chef and configuration management tools to help devsOps deal with the complexity. However, the cloud computing and specially PaaS platforms has that extra edge, beyond puppet, in that, application management and deployment is now as simple as clicking a button and capacity provisioning is taken care of thanks to auto scaling capabilities. Of-course, the infrastructure for IaaS needs to be still maintained, but if you wish, you may outsource that altogether.
DevOps are facilitators to help get into production faster and stay in production.
The key here is to getting the devOps team to focus on getting things into live environment, both new apps and changes to existing apps. And apps get deployed every day, not once in a week. Sometimes, we would have to revert or add quick fixes within hours or minutes of the last update. So there could be many small changes to apps, and that many regular live deployments. This is a drastic shift to the tradition view of DevOps and application deployment management but some of the industries; especially the social Web oriented businesses do adopt these models already. Enterprises would love to leverage the business benefits of this level of agility the application management platform would bring in.
DevOps are not that “IT team”, they are part of the whole dev team.
The value of DevOps in this era is not dance around with configs and systems and be the hurdle point that others have to cross to go into production. Rather, the DevOps space is changing and they are coming to be part and parcel of the software team. Applications are meant to be live, and we need the DevOps professionalism, like we do QA. We need the systems to not go down randomly, systems to be safe and secure, the system updates with new deployments to be seamless and if updated break it, revert back to the previous known working point without side effects. Like QA, DevOps are a different breed, and developers are not the same. The idea is to get them integrated to the teams and get DevOps and the rest of the team communicate and collaborate and act together.
Team Collaboration and Application Life-Cycle
Application life cycle is not just a set of stages, where a set of roles work on their tasks on their own in silos. Communication and collaboration is a key part of the process. It is also important to know when spring into action and know when others are ready. This is where the notification model around the life cycle transitions facilitates collaboration and the follow up communication.
Application life-cycle is not linear path, but a dynamic state machine.
When developers promote applications for QA, QA team gets notified and kicks into action. Necessary communications as to what areas to focus most on testing can happen. If QA fails, then QA can demote application back to development, and developers get notified. And communication around what failed gets communicated and issues reported pointed to.
Cloud PaaS capabilities will revolutionize the way we run our agile projects.
Comments
- Harsha Purasinghe