Upgrading remains a major project for many on premise and legacy applications. It is really quite a pain and this is one reason why I favor Cloud platforms. In the meantime, I hope that I can do upgrading for the last time. These are some tips that the future may not be using for upgrading exercise.
Get the Right Team
The upgrading team is usually a separate team from the support team. This caused a disconnect with miscommunication and the need of knowledge transfer process. There are also instances where upgrading team miss out key components. After all, we suppose the upgrading team to be well versed in the new application. However, the team must involve a right mix of support team to understand the application landscape.
Agile and Systematic
Unfortunately, many upgrading projects follow waterfall model. I favor Agile and systematic approach. In all upgrading project, you need to be systematic in the changes you are doing. You must also be agile to adapt to new options of the upgraded components become a showstopper. Therefore, waterfall model is painfully slower and subjected to delta changes.
As long you are having legacy or on premise application, you will still be having upgrading nightmare. A move to Cloud will cut these costs and time as upgrades are done seamlessly backend. Hopefully, we will not suffer more upgrades in future.
In many projects, the rules of engagement is often vague and undefined. This is because standard communication plan assume a constant and stable environment. This is how waterfall projects are being run in the past. In agile projects, close collaboration is required and this blurred the formality of communication. To avoid misunderstanding, it is recommended to set some guidelines for rules of engagement with one another.
If you are familiar to Scrum, standup meetings are timeboxed to last 15min. In reality, this often overruns if you have more than 3 people. You should review this communication internally and give a realistic timebox. There are some who are not able to articulate the objectives within 5min. If so, there should be other breakout sessions to handle this. Thus, you must be disciplined to time box accurately.
The sprint retrospective is another good concept that can be used rules of engagement regardless of project type. Some will remember it as AAR (After Action Review), “post-mortem” or project review. The key communication objectives are to understand what goes wrong and ways for improvement. You can also share the good points and reinforce project communication for the next one.
The basic project rules of engagement can be classified loosely as daily standup and post review like sprint retrospective. These encourage project team to collaborate and communicate closely with one another.
ORDS (Oracle REST Data Services) is a cool feature to extend your Oracle database for integration via HTTPS. It will change and digital transform the way you interact and integrate to applications. This is why you need to enable ORDS for your database for future API.
Why Change to REST?
REST is changing the way applications can quickly communicate with each other. It is much simpler to setup than SOAP/XML. In a way, it can replace many of legacy integration with XML and flat file. ORDS helps to enable access via RESTful web services to data and stored procedures in your Oracle database.
Time to ORDS
Another key advantages of ORDS is security and real time performance with your Oracle database. The REST API endpoints are quick and simple to setup. The quick deployment reduces traditional integration method by eliminating the need of complex middleware setup. JSON format and paged results helps to support the ease of data responses.
If you are using Oracle database, it is time to ORDS and enable your REST capabilities. This will digital transform your integration method for other applications and agile your development.
Rapid Application Development (RAD) is around since the days of Visual Basic (VB). Since then, there is a preference of lightweight and low code framework with Agile approach. APEX (Application Express) is one such framework offered free with Oracle database. What does this signal for heavyweights like Spring or J2EE framework? Should you switch to low code like APEX?
Ease of Maintenance
The key push factor to switch to low code framework like APEX is the ease of maintenance. This helps users to focus on solving business problem rather then creating technical solution. Changes can be made and deploy quickly. This suits high complexity and exploratory problems where scope is largely unknown.
Low code environment places emphasis on outcome instead of being expert in thr programming language. Thus, platform like APEX suits users who are not technically inclined to setup entire infrastructure like servers and database. This emphasis business driven skillset like problem solving instead of technical skills. Users can also realised business solutions quickly with low code deployment.
The switch to low code platform like APEX will be growing. This is driven by the need for agile solutions to solve changing requirements. Usage of APEX also allows citizen developers to co-own and maintain the development.
Outsourcing will be on the decline as Cloud architecture grows with adoption. Many organisations are now turning to co-sourcing model because Cloud allows you to self service very quickly with configuration. This allows you to Agile quickly and adapt to different business needs. So, how should organisation make the switch to co-sourcing?
Recalibrate your Team
The first step to co-sourcing is to recalibrate your team skillset. This means your team will need to start to utilise their technical skills. A good start is to take on some enhancements changes internally instead of outsourcing to vendors. However, there are some teammates or management who cannot make the switch to this model. You will need to make the hard choice to rotate your team for co-sourcing inclined resources.
Co-sourcing with Vendors
The next step is to leverage your vendors for co-sourcing needs. You will also need to communicate to vendors your co-sourcing objectives. Both parties must build on mutual trust and work towards open knowledge and transfer of skillset. There is a misconception that co-sourcing will lead to a decrease of business for vendors. On the contrary, business will increase as more innovations can be implemented.
IT Co-sourcing is expected to overtake or even replace existing outsource model. There are two key steps to convert your organisation to co-sourcing. First, you need to recalibrate your team to build on technical skills. Then, you must communicate to your vendors for this vision and work mutually to achieve this model.
Configuring software product is the key trend and reason of moving to Cloud. Some key characteristics of configuration approach are real time changes, hotfix and self service features. Many traditional project manager have misalignment to apply development methods for configuration model. If you are one of them and new to configuration approach, you may find these tips useful.
Digital Transform Mindset
Digital transformation is a main component for configuration model. Many will think digital transformation is about application changes. In reality, this is transformation of your mindset to a configuration approach. You should be inclined to review products that are highly flexible and configurable instead of turnkey method. This is a commonly seen in many local offices where stakeholders try to engage local solutions to solve a global problem.
Tips for Configuration Project
If you are new to configuration project, you will likely need to adapt these few tips.
Cloud allows configuration at various levels like infrastructure, applications or services.
Train insource SME (subject matter expert).
Organise your teams for configuration capabilities.
Engage management support to adopt configuration platforms.
The constant market changes and COVID-19 is spurring the configuration market. Many resources and education stay entrenched in software development practices. It is time you switch your mindset and embrace configuration practices. This way, you can stay relevance and adaptive.
A project closure is a last step in waterfall project. It usually signal the start of financial depreciation. If you are employing an Agile model, the view of project closure will not exist. How should this be justifiable for financial view? You may need to operate in a waterfall agile model to fulfill the financial concerns.
Relating Sprint Review
Perhaps a more appropriate and foreign terms for finance is sprint review. This is the end of sprint. It will take a lot of understanding to educate the financial how sprint review relates to project closure. You may group a few key sprint reviews into milestone for the purpose of financial obligations. A typical grouping could be a major version from sprint. This may usually be a monthly to quarterly frequency.
The project closure view is different to Agile. The view to close an Agile project will mean the end of product life. You may want to communicate this end as early as possible. This will allows financial to compute from a budgeting standpoint. Thus, product owner may consider roadmap visibility for the product end.
Project closure have a different meaning for Agile projects. Meanwhile, finance numbers remained entrenched in waterfall mindset. It will take a few more years before a sound finance instrument is geared for Agile. For the moment, I will need to use waterfall agile for my reporting and implementation.
Application downtime is getting lesser and lesser with Cloud computing. Users are more demanding without the need of downtime. Thus, we need to move to the approach of hotfix and high availability environment.
Shift to Zero Downtime
The design of zero downtime will require a digital transformation approach to your entire architecture. Another consideration is utilisation of the Cloud platform for different high availability approach. As this approach will incur additional cost like licences, you may want to evaluate a switch to pay as your use model instead of fixed licensing.
Developmentwith No Downtime
Another key change is your development approach. This must be changed to reflect deployment with no downtime. Instead, hotfix and patches must be applied seamlessly without any downtime or impact to user operations. Therefore, your development will need Agile and DevOps to enable this approach.
If you have intention to move to a services with no downtime, it is time to reform your architecture and development approach. This involves utilisation of Cloud platform and Agile development to achieve this vision.
Business analysis have process that involves the understanding of stakeholder. This process is called stakeholder analysis. This process is covered with assumptions made during during projects formation in Waterfall SDLC. Similarly, these stakeholders analysis can be conducted with Agile approach.
Agile your Knowledge of Stakeholders
In traditional project, we usually set a baseline on the understanding of stakeholders. As project progress, we seldom revisit or update our understanding of stakeholders. In an Agile project, stakeholder analysis become similar to your project cycle. Your knowledge of stakeholders are constantly updated with each Sprint.
Agile in your Stakeholder Analysis
Agile is result driven and focus on positivity in clearing the backlog. There is always a bad or black spot in all stakeholders. Like Agile, your stakeholder analysis must be aligned with positive nature and definition of done. Another key area in your analysis is to seek out close collaborator among your stakeholder. Not all stakeholder suits Agile and your analysis must identify Agile stakeholders.
Stakeholder analysis differs from Waterfall to Agile approach. You will need to seek out stakeholders who suits Agile in the course of your Agile project. The stakeholder analysis requires deeper understanding and iteration similar to your Agile.
If you are an Agile practitioner, you will realise that there is always a gap between Agile and Management. Not much have been stated on Agile for Management. Unlike Waterfall model, Agile is not big on reporting and generating of status report. Here are some tips on engaging management with Agile projects.
Waterfall model is so entrenched that entire reporting structure to management revolve around this perspective. The first step is to educate Agile and the differences between the Agile and Waterfall to the management. You need to set Agile expectations with your Agile champion. These champions must preferably from top management. You need to have a holistic approach to share the Agile approach to users as well.
One of the best part of Agile is lesser admin reporting. This leaves you more time to focus on what is to be done. Of course, Agile is timebox at duration that management can participate as observer. For example, management can join in daily stand up that should last between 5 to 15 mins. The most suitable updates for management will be the sprint review where they are invited for their feedback. This typically last two hours for a two week sprint.
Agile does not require formal reporting to management. We should always seek to educate management on Agile events like spring review. This is where management can provide feedback on the product. After all, this allows the Agile team to focus on delivering a “done” product.