Kazutoshi Ono: Japan Inc. in the Cloud Era
Local insider reveals current enterprise cloud usage trends in Japan and what to expect moving forward as technology and mindsets evolve.
For many Japanese enterprises, the strategic adoption of cloud computing has progressed from something they were researching and planning to a high priority initiative requiring immediate action.
However, there is confusion about how to approach this new generation of infrastructure. Executive decision makers are looking around to assess the current state of affairs in the enterprise sphere and get a sense of where things are moving. They want to make the right strategic decisions that will enable their organizations to take advantage of new technologies.
To learn more about these trends and issues, we spoke to Kazutoshi Ono, CTO of Tokyo-headquartered systems integration services provider, Saison Information Systems.
He is also the Founder and CEO of Appresso, a subsidiary of Saison Information Systems, that develops and supports several data and application integration middleware products.
It’s a lengthy interview, so we’ve divided it into the following sections:
- Enterprise Cloud Trends to Date
- Enterprise Cloud Usage Today
- Migration from On-Premises to the Cloud
- Challenges Faced by Corporate IT
- Changes in Mindset and Methods
- The Outlook for Enterprise Cloud
Part I: Enterprise Cloud Trends to Date
How would you describe the progression of enterprise cloud usage in Japan thus far?
Until last year (2016), the general view among executives seemed to be that cloud was an option to be considered for specific uses. That was especially the case back in the early days of the cloud era.
Cloud is ideal for situations with a high variation in resource requirements or for short-term needs. For example, hosting a campaign website during a limited period, or for dealing with large spikes in traffic due to year-end shopping. It’s also suitable for systems that are only needed during the daytime.
Another situation is when resource needs are unpredictable. For example, if a TV commercial is unexpectedly successful or a product is introduced by a celebrity on a top TV program, and there is a spike in traffic to the website. Setting up and maintaining dedicated servers that can handle such high loads is both labor-intensive and costly. But, if you do not prepare for the peak, you could miss out on an excellent opportunity to make sales as the system is overwhelmed and goes down. In this situation, the cloud is really the only sensible solution because it can scale elastically in proportion to the demand and you only pay for what you use.
These types of situations are ideal for cloud usage, and this is where cloud vendors focused their marketing messages. It’s analogous to rental cars. If you own a car, it incurs ongoing costs. But, with a rental car, you only pay for the time you use it.
What about enterprises’ internal systems?
This was case-by-case. Generally, the loads experienced by systems performing in-house functions are highly predictable, without much variances in highs and lows. For example, the employee attendance tracking system may experience a mild spike when people clock-in at the start of each workday, but nothing extreme. So, if such a system was hosted on-premises, there was no significant incentive to migrate its functions to the cloud.
However, the cloud would be used in cases where a particular business division or team needed to set up a system for use in a project. If it wasn’t clear how long the system would be required, setting it up on the cloud was easier and more flexible. So, when it comes to internal systems, we tend to see the cloud used for isolated and specific functions within an organization with a temporary or indefinite use period.
Sometimes, a cloud-based solution such as Salesforce was chosen because it was deemed the most suitable option or circumstances demanded it. However, it was just for part of the business, rather than all functions within the organization as a whole.
Part II: Enterprise Cloud Usage Today
How have attitudes changed towards enterprise cloud usage among Japanese executives?
Things have changed significantly over the past year or two. Now it is no longer a question of whether or not the cloud would be suitable for a given use. Instead, the general attitude has shifted to regarding the cloud as a natural choice for most situations.
Compared to the total cost of ownership (TCO) of on-premises systems, having to set them up and then perform ongoing maintenance, the cloud is much cheaper. Speed is another defining factor — you can get started with something on the cloud very quickly.
So, since a couple of years ago, we’ve come to think of, “cloud first,” meaning that we’d first build and test a new system on the cloud before considering the next steps.
Has cloud usage become commonplace in the enterprise?
Until recently, most case studies of large-scale cloud adoption were seen in the game industry. Other than that, the cloud was mainly used for non-core information systems. In particular, it was relatively rare to see adoption by financial institutions.
Each year, I attend the giant trade show run by Amazon Web Services in Las Vegas, AWS re:Invent. In 2012, the NASDAQ OMX Group announced the launch of FinQloud, a new cloud computing platform powered by AWS and exclusively designed for the financial services industry.
From that point on, there was about one new major case study seen each year from the financial sector. However, it seems that last year (2016) was a significant turning point and several more have emerged since.
Across all industries, today, we are seeing more cases of large organizations that are “cloud-only” and “all-in-the-cloud,” including having migrated legacy systems to the cloud.
What changes have you seen in Japanese organizations?
Last year (2016), while there was a general trend of forward-thinking executives in Japan moving towards going all-in on the cloud, and becoming “cloud only,” the more conservative organizations were still taking a wait-and-see approach.
The decision to use cloud infrastructure tended to be made by the IT department or driven by a particular team’s need to use a specific online service. It was a departmental decision and not something that would reach the executive level. The CEO wouldn’t have gotten involved in such details.
However, in January this year, Mitsubishi UFJ Financial Group became the first major Japanese bank to adopt cloud computing with AWS as their provider. Significant cost savings and increases in operational efficiency were forecast. From that point on, even conservative executives began to ask, “If the financial institutions are starting to move to the cloud, why aren’t we?”
Decisions shifted from being technical choices to being strategic decisions made by the board. Of course, for an organization to migrate everything to the cloud is a huge commitment that affects its fate long-term.
While there are many cloud services available, behind each is a company that provides the fundamental infrastructure (IaaS — Infrastructure as a Service). Therefore, it is critical to consider what kind of relationship will be had with the IaaS vendor and whether they are going to be compatible and dependable for the long-term.
When choosing a cloud provider, are companies taking into account which ones are being used by their competitors?
Selecting a cloud provider is less about what technology is being used, but rather, a decision about what to use as the foundation of your enterprise and which provider to work with. As a result, there are cases in which, rather than just being a line item within the budget, the choice of cloud is reviewed holistically as a critical part of the overall business strategy by the board of directors.
Executives have moved beyond the stage of discussing whether or not to use the cloud. Nowadays, the cloud itself is treated with a level of priority and weight that we haven’t seen before.
Part III: Migration from On-Premises to the Cloud
What is one of the major concerns for organizations thinking about moving their on-premises systems to the cloud?
In the early days, when people were starting to talk about enterprise cloud use, it was said that RDBMS (relational database management systems) would not be suitable for the cloud. Instead, everyone would switch to NoSQL (non-SQL or non-relational) databases.
What is the difference between RDBM and NoSQL?
When people talk about databases, they are typically referring to RDBMS. SQL (Structured Query Language) is a domain-specific programming language designed for managing data held in an RDBMS. This technology has been used widely in enterprise systems for many years.
Roughly, we can regard NoSQL as a term referring to databases other than RDBMS. A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases (RDB). NoSQL databases have seen a surge in popularity in recent years as they overcome many of the functional limitations of RDB and are better suited to the cloud, big data, and real-time web application usage scenarios.
Have many Japanese enterprises ditched RDBMS for NoSQL?
In my role as a member of the MIJS (Made In Japan Software Consortium) Product Technology Reinforcement Committee, I gave various demonstrations of how transactional processing would work for enterprise systems in the NoSQL era.
However, when you take a close look at most enterprises today, they are actually using RDBMS in the cloud. Of course, they wouldn’t use RDBMS for scenarios such as collecting data from IoT’s sensors. However, transaction systems are often still RDBMS.
This is because there are SQL experts who have been perfecting their craft for many years. By utilizing their experience and skills developed so far, they are able to build a stable system. Personnel skill sets don’t change so quickly. As a result, while systems have shifted to the cloud, many do not yet run NoSQL databases.
How have Japanese organizations been approaching their migration from on-premises to cloud?
A cloud migration option favored by many organizations is the “Lift-and-Shift” approach. Essentially, “Lift” refers to replicating on-premises systems in the cloud without re-building them. Then, later, they can go through their portfolio of systems and sequentially “Shift” them to be optimized for the cloud.
This enabled them to migrate to the cloud without changing to NoSQL. That was considered an acceptable first step. For Saison Information Systems as a system integration services provider and our customers, this was seen as a safer option because we weren’t changing everything just for the sake of it.
It was essential to “Lift” as the first step, get used to the cloud, and gain an understanding of it. This way, they could continue with the existing system architecture. However, to have the intention of never changing anything isn’t productive so they would look through to see what could be updated. For example, converting the storage to be cloud-optimized. Rather than changing everything at once, they would incrementally adjust and upgrade parts based on their current know-how.
Joi Ito, Director of the MIT Media Lab, emphasizes “Practice over theory;” the principle of first taking action. By starting small, you can learn from your experiences and begin to figure things out.
Rather than thinking that everything old must be immediately discarded, it is more practical to migrate to the cloud in phases. Therefore, first, “Lift” everything to the cloud. Later, the “Shift” can be made in parts so that eventually everything becomes “cloud-native;” configured to exploit the advantages of the cloud computing delivery model fully.
For example, in the case of AWS (Amazon Web Services), at first they might just move from on-premises, and next try their scalable storage service, Amazon S3.
How can organizations overcome internal resistance to this kind of transformation?
While it’s easy to talk about “digital transformation,” in reality, what is first required is “skill transformation,” which is not so simple. It’s not feasible for most organizations to suddenly switch to a system with NoSQL overnight.
On the one hand, it would be a waste to forsake the SQL skills and experience accumulated over many years, however, if nothing changes then the organization will fall behind in competitiveness. It’s, therefore, best to undergo a skill transformation gradually rather than trying to change everything at once. This applies to both systems integrators and end users. Ultimately, the key is mindset transformation.
Moving existing systems to the cloud is, in itself a major challenge. During the process, you will discover that things you thought would be obvious and easy turn out to be challenging. There is significant risk involved.
Therefore to avoid getting caught in a rut during the transition, it’s essential to carefully plan to do it in stages. For example:
- Rather than moving all on-premises systems to the cloud at once, do it in phases, linking remaining on-premises systems with parts that have been moved to the cloud.
- It often makes sense to first transition the lower layers, which are closer to the infrastructure.
- Rather than rushing to convert to using NoSQL, start out by continuing to use RDBMS.
Part IV: Challenges Faced by Corporate IT
How would you describe the traditional approach of Japanese enterprises towards development?
Until recently, most large Japanese organizations seeking to develop business systems would go through the stages of planning a system, defining its requirements, external design, internal design, and detailed design. They would have a cumbersome planning process involving many meetings to decide the specifications and even preliminary meetings to prepare for those main meetings.
Then, when it came to coding, they might do it in-house. More commonly, however, they would outsource the coding work to a systems integrator. Of course, there are advantages to outsourcing such work. However, many organizations that used to build things in-house came to over-rely on external resources.
Often, the systems integrator would need to bring in someone from outside to implement the development. As a result, the person who did the planning and the person who wrote the code were quite removed from each other. There could even be several layers in between them. That was often just how things were done, and so everybody felt it was the natural course to follow.
What problems arose from this approach?
Since the customer has over-relied on outsourcing, their personnel no longer have development skills. They are making requests, but don’t really understand what is going on.
To make things worse, from about ten years ago, we started seeing new graduates join systems integrators. For some reason, although they had no development experience, they were put into the role of project manager (PM) and made to write specifications documents.
Satoshi Nakajima, Founder and Chief Scientist of Xevo, wrote in his article, “Software Specifications are Like Recipes” [in Japanese],
“A dish made from a recipe written by a chef who has never cooked cannot be delicious.”
The customer is entrusting the development of the IT system and risking the reputation of their organization by using a recipe written by a “chef who has never cooked.” Furthermore, the persons who actually write the code are following directions they don’t understand. Then, when problems arise, they are caught in the middle and scolded by both the customer and their employer. Unfortunately, this has become the standard arrangement within the industry.
They go through the arduous process of writing a document and doing the coding only to realize that it doesn’t work the way they wanted. The resulting system design is clunky, slow, and painful to maintain. However, at this stage, if you’re going to make changes or corrections, it results in further problems. Not to mention the additional time and cost.
Since all the development was outsourced, even to make small changes or adjustments require making a request to the subcontractor who is often subcontracting again. The party in between may take a margin of two to three million yen ($20,000 to $30,000) each time.
Later, when it is time to scale the system, there is pressure from senior management to increase the number of subcontractors being used to expand the scope of the project.
How should they change moving forward?
Some customers are beginning to realize the cost inefficiencies of this way of doing things and that it prevents them from moving at the speed required by today’s business environment.
People didn’t always take this inefficient route. They used to just get in and make things by themselves. Nowadays, we can return to that direct approach thanks to the cloud.
Affecting change is difficult. Furthermore, forcing change for the sake of it can be counterproductive. Of course, people can’t suddenly change their skill set, but the mindset can change quickly, and that’s what needs to happen first.
Today, the customer can hire someone in-house with the requisite technical skills. Then, the person driving the project can sit down next to them and have them build a prototype on the cloud. Next, it can be tested and adjusted until they achieve what they want.
Such in-house production on the customer side is becoming more common. This is partly because they have recognized that industry structure is twisted. However, it is also because they now need to be able to respond to the demands of the business climate with speed and flexibility.
Part V: Changes in Mindset and Methods
How would you describe the philosophy behind this new approach?
One of Joi Ito’s quotes I like is, “Compasses Over Maps.” He was describing how our approach needs to change now that we are in an After Internet (AI) society.
In past eras, it made sense to plan in detail, create maps, live accordingly, and based on this, decide the organization’s direction. The path to success was learning from the experiences of elders and predecessors.
However, now the speed of change throughout the world has accelerated, and uncertainty has increased. The topography changes while writing the map. The value of maps and plans has not disappeared, but situations where drawing maps are not useful have increased. The times have changed.
We’re now in an era where we must depend on the direction in which our compasses are pointing. As a result, the ability to predict whether a particular course may lead to a cliff or a golden age has become crucial.
What milestones occurred that brought forward this change in thinking?
From around 1995 when the Internet explosively spread, the sense of incongruity that “There’s something wrong with this way of working” gradually grew.
Change was further ushered by the 2001 “Manifesto for Agile Software Development,” which began the so-called “Agile” movement.
How have things been evolving in recent years?
Things are changing. The Digital transformation (DX), i.e., the application of digital technology in all aspects of human society, has progressed to the point where the change is palpable.
In particular, younger organizations are more likely to take new approaches such as lean startup methodology, design thinking, extreme programming, and scrum. In such cases, the planning and implementation are closely linked.
I recently held a retreat for developers from the various business divisions and departments of Saison Information Systems to focus on topics such as cloud and agile software development. The great thing about such retreats is you can create an entirely new environment that departs from established norms.
In this situation, the end user is able to express their needs without much distance between them and the developer. In other words, the person who is saying, “We need things like this.” is sitting next to the person who is writing the code. They’ll also be living together, hanging out, and playing ping pong. It is a situation that isn’t usually possible, so the time from idea to implementation is short. As with the principle mentioned above, “Practice over theory,” once you experience it, you’ll quickly understand it.
Part VI: The Outlook for Enterprise Cloud
How do you expect the approach to development to evolve in Japan moving forward?
I think that the use of methods which emphasize speed are becoming more common, even in large and long-established enterprises.
There are cases where the cloud accelerates things further. For example, when it is necessary to create an infrastructure environment, conventionally you would download, install, and set up a database, which could be time-consuming. But in the cloud, you can prepare the resources you need quickly.
As we move into the cloud era and adapt our approach to development accordingly, there is less distance between the end user and the coder. This accelerates the cycle of trial and error, allowing hypotheses to be validated.
These days, with platforms such as AWS, if you need an RDB, you can spin up Amazon RDS and try things out. Even if you want to prepare 100 databases, you can do so immediately. If you need to try something with a data warehouse, you can efficiently use Amazon Redshift. Then, if it doesn’t work out or you no longer need it, you can quit it immediately.
Developers obviously want to avoid building something and realizing they went down the wrong path. Building on the cloud is ideal because it allows you to get started quickly on a small scale and cancel any services you no longer need.
The old approach was spending hours creating documents and having meetings to deliberate over what kind of system to build, how to implement it, and what infrastructure to use. This would consume a lot of time before even starting. With the cloud, you can try things out immediately.
When you want to reduce the distance between the side wanting the system and the team performing the implementation by doing it quickly and taking an agile approach, the cloud is ideal. Indeed, the cloud is making this approach much more common.
The coder can sit with the person requesting the work, listen to their requirements, and if they work carefully, try putting together a prototype within fifteen minutes. Then, they can get feedback immediately, make adjustments right there, and check if the changes worked or not.
How are you developing the skills of your engineers?
I hold regular camps for our developers that allow them to exchange information and skills, use their cloud expertise, and experience what is possible with today’s technology. They quickly learn that there is a world which functions in an entirely different way from the traditional paradigm. We take a “Practice over theory” approach.
Of course, we shouldn’t blindly throw away all the past ways. As per the Manifesto for Agile Software Development, we acknowledge that there is value in the conventional approach, but we value the new method more. “Maps” and “plans” are still necessary, but nowadays, we focus on the “compass.”
If you actually try out the new way, you can begin to notice the fantastic things companies which use it are doing, and can evaluate it. However, if you just continue with the way you’ve always done things, will you be able to beat such a company? This process brings answers to questions such as:
- Why use the cloud?
- Why change the development approach?
- Why do things in-house instead of outsourcing everything?
Once people’s mindsets shift, they understand what needs to change.
Kazutoshi Ono is the CTO of Saison Information Systems Co., Ltd. He also serves as the Founder & CEO of Appresso Co., Ltd. and was the originator of their application integration middleware, DataSpider Servista, which has been used by many organizations migrating to the cloud.
