Having an oversea sites can run into all sorts of networking issues if you are accessing these websites in China. This is because of the well known firewall of China. You will need alternative solution if you have users in China that use websites outside of China. If no, you will be running into countless uncontrollable risks.
Time to Locate a Mirror in China
Unlike other countries, it is favorable to have a mirror sites in China. You can consider this option if you have a large user base in China. Although there are conditions to setup a website, the returns will outweigh the risks of blocks from China firewall. The mirror site can also serve as your redundancy or CDN (Content Delivery Network) for high availability and added performance.
If you do not meet the conditions for a mirror site in China, there are other options for you to consider. You can transmit your data real time via your VPN instead of the regular internet. Using VPN have its advantages with faster latency. However, there are also risks because they will be subjected to firewall blocks and it will also cost more. You may also consider store and forward method where you accumulate your data for transmission. Although you may not have real time data, you can manage your user expectations and controlled your data transmission at a lower cost and systematic manner.
Having users in China is a tricky approach for your website. If you have a large user base in China, it is worthwhile to invest a mirror site within China. Otherwise, you may consider lowering user expectations and opt for non real-time or less availability solutions.
If you have done many application projects, it is common to find that exceptions are often being provided as a rule by users. This is a key reason for major scope creep when you try to cater to exception. Is exception a rule? Can this be considered as a rule?
Exception is a Process
The first approach to exception handling is educate users that exception is a process to be managed. It is not a rule that system is able to followed. A rule existed from known set of variables. On the other hand, exception represent special scenarios and unknown variants. Thus, this distinguish exception from a being rule.
Exception is Unpredictable
The second key characteristic of exception is the nature of occurrence. It is unpredictable and sporadic. In fact, some exceptions break the established rules. This is where users demand that exception be made as a rule. That exception will conflict with existing rules. If you attempt to fit the exception as a rule, scope creep will occur.
User education is important to distinguish exception from a rule. Exception often break existing rule and must be handled as a process. Usually, users cannot determine the frequency of exception. After all, exception is not a rule!
We had an outages yesterday that was totally unexpected. It was so big that the major news reported them i.e. Akamai outages. It was surprising because we would have thought this type of outages were a relic of the past. How should outages being handled in a world where users cannot tolerate 5 min of downtime?
Formation of Outage Team
Do you have an outage team? It is likely majority of organisations do not have an outage team. Neither are outage drills conducted in large scale for the organisation. You can relate this like a fire drill where you will have a fire drill team for your entire buildings. This team is usually cross functional and well drilled in various skillsets from infrastructure, security and applications. Although this team could be costly, it is worthwhile to note that outages may cost a 100 times more.
Outage management is different from disaster recovery. Disaster recovery usually deals mostly with internal applications or related downtime. These SOP (Standard Operating Procedure) could be formal processes with your external parties. When outage happens in the old ways, it usually starts with a Sev1 (Severity 1) and manage with standard incident management process. It will take an hour or more before this is deem an outage. The slower pace and passive nature of incident management may not suit today’s outage.
Outages are no longer isolated in nature due to Cloud and networked environment. Case study like Akamai outage will lead organisations to consider a need for outage team who are highly trained and focused to manage outages swiftly.
Our lifestyle is like a big system deployment. The Covid-19 pandemic has created another rollback to Phase 1.5 (aka Phase 2 Heightened Alert) in Singapore. It is time we get used to the roller coasters effect from the pandemic. What can these effects teach us?
Single channel industry needs to undergo massive flexi calibration to multichannel. A major shift will be high touch industry. These roles will need to toggle between face to face services to digital services. It is no surprise that our feedbacks and emails suddenly get answered with slower responses due to overwhelming surge in online services. This lead to very poor satisfaction with online customer service. On the other hand, physical stores have to layoff staffs because there are no customers to serve.
The digitalisation effects create a huge gap in consumers due to the toggle measures of the pandemic. These gaps include IT savviness, vaccinated vs non vaccinated or even capabilities to provide digital presence. Sadly, those that fall behind will soon be forgotten as we get used to the pandemic effects or the new normal. It lends an important lesson to incumbent industries that pandemic can be a nasty disruptor for some or opportunities for others.
The roller coasters measures of pandemic will be anticipated. Meanwhile, the casualties will be tough to handle and damages be done. We can only calibrate our mindset forward to avoid the bottom end of the digitalisation chasm that comes with it.
System demo is getting easier now. However, a demo is not to be mistaken for POC (Proof of Concept). Non IT users often cannot differentiate between demo and POC. Here are some quick tips to know the differences.
Demo vs POC
The distinct differences between demo and POC are related to time, scope and cost. Demo are faster to show because you will be using existing test or demo data. Demo scope is limited to standard features that have already been implemented. Best of all, demo usually is free of charge. In contrast, POC may not be free because you would be setting up customer data for POC. In some cases, you may configure specific features pertaining for customer requests. Thus, POC will take a longer duration to be planned and setup like a project.
Set Your Expectations
When you are going to showcase your system, it is important to set the customer expectations. Non IT users also have the misconception of using excel for simulation and anticipate the system to behave in similar manner. The expectations will determine if your customers are looking for a demo or POC. You will need to plan your schedule carefully based on these expectations.
It is not surprising to see sales or non IT users mixing up the customer expectations for demo or POC. You may find yourself in a crunch to provide freebies POC as a disguised demo. Therefore, it is timely to educate your users on the key points for demo and POC
We have often know that there is no Project Manager (PM) role in Agile project. However, many organisations still retain the symbolic PM role. This is not cost effective and why does organisations preserve the PM role.
Why PM is Staying
Unfortunately, PM hold a great political position and influence for many organisations. While there is a shift from traditional waterfall to agile, PM role continues to remain for a main reason. That main reason is coordination. The PM role is now relegated to a coordinator role. This role is focused to coordinate the reporting between the project and management. In other words, this information gatekeeper role places the PM in an influential and yet non productive position.
Although Agile does not require PM, there is a dire need to remove information gatekeeper. Therefore, you are seeing an emerging role of Agile PM. This role are actually a hybrid of Agile developer or product owner who take on the additional efforts to connect with the management. In another words, they bridge the gap between Agile team and management. Effectively, this should remove the information gatekeeper influence and gap.
For many Agile team, we have agreed that there is no PM. However, the reality of PM existed for many organisations. These PM may not understood Agile and become information gatekeeper between Agile team and management. While a role of Agile PM is emerging, the battle continue to either remove or bridge the gap with Agile PM.
A major advantage of interpreted programming languages is ability to read the source codes. It is also lightweight than Java and can easily setup to run without much errors in the development environment. This makes it a great favourite with non computer science users. I am also one of those who have a preference over interpreted programming languages.
Users Self Service
The citizen programming community is getting really vibrant. This will translates to users in organisations. Compiled languages are machine codes and cannot be easily viewed by users if there is an error or bug. You will need to setup the development environment. For interpreted programming, you can self service to read the erroneous codes without the need of complex development environment.
For the newbie in IT project, hypercare must be a new term. There are many approach to conducting hypercare. It can be confusing over the difference between standard support flow and Hypercare. Often, cost is proportional to the duration of Hypercare. This means that the longer the Hypercare period, the higher the cost. These are some of the standard methods used for you to understand Hypercare quickly.
Hypercare consist of the following basic process and approach.
Assurance to fix bugs during the Hypercare period, also known as warranty.
Dedicated resources available during the Hypercare period.
Quicker turnaround to provide issue analysis similar to DevOps process.
Not in Hypercare
There are a few areas that are not covered in Hypercare. Notably, they are mainly related to changes.
Change management are not the scope of Hypercare.
User change request will fall outside of the Hypercare scope.
The Hypercare only covers the intended system. Related issues that are found to be caused by external system are not within Hypercare scope.
Hypercare is a common term used for project warranty. Like all warranty, it is constraint to the intended system and have conditions. The coverage and duration of Hypercare is proportional to the amount of money you are willing to fork out. Do be aware that Hypercare is not a God Mode that solve everything that happens after Go Live.
Today, I have a very interesting discussion on data modification process. There are two integrated systems with a constraint of one system accepting modified data. This is a very standard constraint in many networked applications. How should you overcome this constraint? This is where you need to have a very good SOP (Standard Operating Procedure).
SOP is Cost Effective
A good IT person should always learn business process and how to adapt SOP with system flow. Application does not work on its own but in support of SOP. In most cases, it is more cost effective to handle exception scenarios instead of customising. A good SOP works hand in hand with application. These combinations will lead to a balance trade off on standard applications with different customers.
SOP helps to simplifies many business process. This allows your system flow to be direct and fast. A poorly designed system often exist with no SOP in place. The lack of governance leads to many data errors and system interlocking rules. Thus, you need to think of SOP as the approach to simplify your applications.
SOP exist long before IT have arrived. The full strengths of SOP can be realised in the tightly coupled systems. Without SOP, these coupled systems will hinder rather than accelerate your data flow.
Projects are usually encountered with a constant that is consistent. I like to call it a constant delta, oxymoron intended. For the noobs, this is frown upon and recorded as issues. Instead, a positive mindset is encouraged to embrace these delta. You will notice that Agile is unable to exist in organisational context due to traditional structures, policies and roles.
Another View of Delta
Delta management is rarely emphasised because traditional project management focus on fixing scope, time and cost. Variables are deemed to be risks with negative impacts for projects. This view of delta does not change until the recent explosion of Cloud technologies with Agile. The Agile project is a 180 degree view to regard change as constant. This paradigm shift to handle changes instead of freezing scope brings upon a new view of Delta.
Human Avoid Delta
Unfortunately, organisational view remains entrenched in fixed scope. The slow rate of change is consistent with human reluctance and avoidance to change. There are no revision of organisation policies or financial tools to manage delta. This lack of knowledge and uptake will persist for the next 5 years until all applications moved fully to Cloud.
Agile is the best technique to handle constant delta in projects. For many Agile practitioners, we are frustrated by the lack of delta management in the organisations. The gap between Agile and constant will remain unless there are more efforts to focus on how to incorporate delta within organisations.