Articles about Low-Code Development
Cat: ICT
Pub: 2021
#: 2102a
Compiled & Translated by Kanzo Kobayashi
21312u/22816r
>Top 1-1. Low-code frustration #1:
- Maintenance can be hard:
The trickiest part of dealing with a low-code solution is usually a few years down the road. The old system is deployed and running along smoothly, but everyone has requests for fixes and improvements. Many times, these extra features lie just outside the architectural structure of the old, low-code solution and there’s no easy way to add them. If we had the source code, we might be able to dive in and rebuild some of the guts, but we don’t. If the original designers knew the feature would be needed, they would have made different decisions. They might have started with a completely different framework. But they didn’t and now we’re locked in.
1-1. ローコードへの失望 #1:
- メンテナンスは大変である。:
ローコードで開発する時の最もトリッキーな点は、数年後にやってくる。古いシステムが導入されスムーズに可動しているが、いろんな人から、バグフィックスや改善要求が出てくる。多くの場合、これらの要求は古いシステムの構造的な問題の外側にあることが多く、それら要求を追加するのは容易ではない。もし、我々がソースコードを持っていれば、そのコードを調べて、その部分を再構築できるが、我々はそうはしない。もし当初の設計者が、その変更箇所の必要性を知っていれば、おそらく別の決定をしたと思われる。彼等は全く別のフレームワークを使って最初から取り組む可能性がある。しかし、今や、我々は（当初のローコードツールに）ロックインされているので、それはできないのだ。
>Top 1-2. Low-code frustration #2:
- Everyone gets the same thing.:
Everyone who eats at a chain restaurant knows the boredom and lack of surprise. The business model depends on saving money on a standard menu and standard design while also providing a consistent experience, but that doesn’t make it more fun.
Low-code tools offer the same cookie-cutter feel. A good developer with just a bit of experience can often identify the underlying tools with just a few clicks. No matter how many configuration options, splash screens, or customized CSS skins, the underlying mechanism shows through. This can be comforting for some users who want things exactly the same, but it also removes much of the surprise and novelty.
1-2. ローコードへの失望 #2:
- 誰もが同じ結果を得る。:
誰もがチェーンレストランで同じような食事をすると考えると、しまいに飽きてきて感激がなくなってくる。ビジネスモデルは、標準的なメニューと標準的なデザインに基づいて予算を節約するが、一方では同じ繰り返しの経験を積むこととなり、それでは面白みがなくなってくる。ローコードツールも同じで、クッキーカッターのような感覚である。あまり経験のない開発者は、少しのクリックでのツールに同化して行うのが良い開発者ということになる。いかに多くのコンフィギュレーションのオプションや、目立つようなスクリーンや、カスタマイズした多くのCSSの設定があっても、底流にあるメカニズムは透けて見える。これは全く同じことをしたい一部のユーザには助かる機能だが、同時に多くの感激や新規性をもたらすことはなくなる。
>Top 1-3. Low-code frustration #3:
- One size fits none:
The product manufacturers love items that are “one size fits all” because the pipeline is so much simpler. The customers? They often hate them and grouse that “one size fits none.”
Low-code products are easy to use in the same way. There just aren’t that many things for you to change, customize, or code and so you’re stuck with them. They do what they can do and that’s about it. No one ends up happy.
1-3. ローコードへの失望 #3:
- 一つのサイズでどこにも適合しない。:
製品メーカーは"一つのサイズで全てに適合する"という原則が好きである。なぜなら生産パイプラインが非常に単純化されるからである。では顧客の方はどうか?顧客は、その考えが嫌いであり、むしろ"一つのサイズがどこにも適合しない"方が良いと考えている。ローコード製品は同じように使うことが容易になっている。それは、顧客が変更したり、カスタマイズしたりすることが多くないために、コーディングして（独自性を出すことに）固執しているのである。顧客はできることをするだけで、それがすべてという訳である。それでは顧客は満足しないのである。
>Top 1-4. Low-code frustration #4:
- Sometimes coding is easier than configuration.:
Developers have been making a strategic mistake by minimizing the work that goes into configuring software. Maybe it’s because the bean counters compute metrics like the cost of each line of code. Maybe it’s because the suits are always comparing the cost of creating new code with the price of buying an off-the-shelf product. In any case, coders like to pretend that changing the parameters in the configuration files for a platform or tool is no big deal.
Low-code options tend to push the same story: You’re not coding when you’re specifying the algorithms, connecting the database, and filling in the parameters. That’s just configuration fluff and everyone knows that configuration is easy enough to do from your smartphone in a loud bar. But the reality is that those keystrokes might take days or weeks of fiddling until they actually do what they’re supposed to do. The vendors don’t want us to consider it “work” even if it takes longer than actually doing the hard “work” of writing code.
1-4. ローコードへの失望 #4:
- 時にはコーディングはコンフィグレーションより容易である。:
開発者は、ソフトウェアをコンフィグレーションするような仕事を最小化するという戦略的なミスを犯している。それはおそらく経理屋が、（コスト計算として）コード一行一行の数えるようなことをしているからかも知れない。あるいは営業マンがいつも新たなコードを生成するコストと既成製品を購入する価格との比較しているせいかも知れない。
ローコードのオプションを設定する場合は、同じような展開になる。アルゴリズムを特定し、データベースを接続し、パラメータを決める時は、コーディングをすることにはならない。それは、コンフィグレーションの設定であって、誰もがスマートフォーンを使ってバー操作でできるような安易なことである。しかし、現実には、それらのキーストロークでも、想定したように実際に動くまでいろいろ（試行錯誤で）混乱して、数日あるいは数週間もかかってしまうかも知れない。ベンダーとしては、厳しいコーディングをするよりも長い時間がかかってしまうというようなことはして欲しくないと思っている。
>Top 1-5. Low-code frustration #5:
- Too often low-code means flying blind.:
Over the years, developers have created elaborate debugging tools that make it easy to stop the software at arbitrary places and peer deeply into all of the data structures and algorithmic state to see just what is happening. Low-code tools hide all of this from us on purpose and think they’re doing us a favor.
If the low-code parts work as we expect, everything is sunshine and unicorns. But more often than not, something goes slightly awry and we’re stuck without any way to figure out what’s going on inside the black box. We’re flying blind without instruments and looking for any way to get some insight into what’s happening.
1-5. ローコードへの失望 #5:
- しばしばローコードは目を閉じて飛ぶようなことである。
今まで何年もの間、開発者はデバッギングツールを使って、任意の場所でソフトウェアを止めて、データ構造やアルゴリズムの状況をつぶさに調査して何が起こっているかを見れるようなものを開発してきた。ローコードツールは、この作業は全て我々から見えないようにして我々に楽をさせてくれている。
もしローコードの部分が我々が期待するように動くのであれば、すべてはめでたしということになる。だが、実際にはしばしば、何かがほんの少しだけ違っており、それを訂正するためにブラックボックスの内部で何がおきているのか突き止める必要にかられる。我々はあたかも測定機器なして目隠しで飛行しており、何が起こっているのかその原因追求に奔走しているようなものである。
>Top 1-6. Low-code frustration #6:
- Sometimes you just need to insert a function to clean up the data.
Anyone who has written software knows that half of the work is writing the extra little glue code that keeps the data flowing while filtering out the problems. Sometimes the dates are in ISO 8601 format and sometimes they’re in some local preference. Sometimes numbers are integers when they should be strings or vice versa.
Low-code products try to shoulder some of this work by offering filters or switches and these are often enough. But when they aren’t you’re out of luck. The low-code products are in a quandary. Some have experimented with letting you insert arbitrary blocks of code in places, but someone finds a way to misuse them and introduces a massive security hole. For instance, Drupal removed the option of including bits of PHP in places, to close a potential security hole and also increase cache performance.
1-6. ローコードへの失望 #6:
- 時々データをクリーンに保つための関数を挿入する必要がでてくる。:
誰でもソフトウェアを書いたことがある人なら、仕事の半分は余分な小さなグルーコードであり、それがあるから問題部分をフィルターすることでデータの流れを保っている。【Glue code: 互換性のない部分同士を結合するためだけに働く接着剤的なコード】また時には、データがISO8601フォーマットだが、時にはそれとは異なるローカルフォーマットを使っている場合がある。また時には数字が、本来は文字列であるべき所が、数字の整数列であったり、あるいはその逆だったりする。
ローコード製品は、フィルターやスイッチを用意しており、これらの仕事のかなり部分は肩代わりしてくれるので多くの場合はそれで十分である。しかし、不幸な場合には十分でないことが起こる。実際、ローコード製品は時々困惑することがある。ある人は、所々に人為的なコード群を挿入すること試みたり、またある人はそれらの使い方を間違えて大きなセキュリティホールを導入してしまったりする。例えば、Drupalソフトウェアの場合は、所々でPHPのオプションコードを取り除くことでセキュリティホールを閉鎖し、またキャッシュ能力を増加させた。【Drupal: PHPで記述されたコンテンツ作成管理用のOSS Platformである。】
>Top 1-7. Low-code frustration #7:
- Low-code is often inefficient
The promise of low-code tools is that they know what you need and then magically deliver it. The cost of this mind reading, though, is a thick stack of code that deals with all of the strange configurations and odd curveballs that might come its way.
If you wrote the code, you might know that your company only stored its data in CSV files. The team back at low-code headquarters, however, needs to plan for all of the contingencies and that means working with JSON, YAML, and XML, both versions 1.0 and 1.1. There are dozens of formats out there and the low-code sales team wants to make sure that their tool can handle all of them. It’s all about the check marks in the feature matrix.
The result is an impressive piece of engineering, just as impressive as the bulletproof Dreadnought, and it maneuvers with all of the grace and agility of the World War I battleship.
The result is that everything is slower and less efficient. If your deadlines aren’t too tight and your data set isn’t too large, you can hide this by throwing more compute power at the stack. But eventually the bill for the extra-careful code is going to come due.
1-7. ローコードへの失望 #7:
- ローコードはしばしば非効率である。
ローコードツールの約束事としては、開発者が必要なことは開発者自身が知っているということが前提で、それゆえ手品のようにコードを生成してくれる。しかし、開発者の気持ちを理解するためにコストとしては、様々な変なコンフィグレーションやクセ球へ対応するために分厚いコード群が必要となるのである。
もしあなたが自分でコードを書こうとすれば、会社は単にデータをCSV形式でストアするだけで十分ということを知っている。しかし、ローコードを制作する本社側のチームとしては、全ての異常事態へ対応し、また、JSON, YAML、XML, それらのVersion 1.0および1.1を準備しなければならない。【JSONは、JavaScriptの簡易的なデータ定義言語; YAMLはRubyなどで使用する構造化データ】これらには何十というフォーマットがあり、ローコードセールスチームは、彼等のツールがそれら全てに対応できるようにと要求してくる。これは、特徴一覧のマトリックスとしては疑問となる（ような分量となる）。
その結果、エンジニアリング（の作業量）としては (巨大で) 印象的なものとなる。あたかも装甲十分なDreadnought 型戦艦のようであり、第一世界大戦で活躍した当時は、優雅さと迅速性を備えた機動力といえた。【Dreadnought: 20世紀初頭の巨大な戦艦】
そして（ローコードの製品としては）結局は、すべてが緩慢となり効率的でなくなる。もし、(システム納期の)期限がきつくでなければ、データセットはそれほど多くならずに、これをスタックでのコンピュータ能力を増やすことでうまく隠すことができる。但し、その場合は余分に考慮されたコーディング部分に関する(追加料金の)請求書が待っていることとなる。
>Top 1-8. Low-code frustration #8:
- Experience wanted
Many of the top open source platforms are built in popular languages that are taught in schools. There is a vast ecosystem of talent that can take apart and rebuild stacks built in the major languages like Java, JavaScript, Python, or PHP.
Low-code usually isn’t taught because, well, you’re not supposed to need any instruction in it. The devotees will point out that the tools are often written in common languages, but that’s not the real challenge for developers. The challenge is the extra structure bundled into the low-code framework. It’s what you’re paying for and it’s also what your team needs to spend time learning if they’re going to revise or extend the platform.
1-8. ローコードへの失望 #8:
- 経験が必要:
多くのトップのオープンソースプラットフォームは、学校で教えてくれるような人気のあるコンピュータ言語によって作られている。これはJava、JavaScript、Python、あるいはPHPといった主要なコンピュータ言語で作られた、ばらばらなコードをスタックとしてまとめることができる能力という巨大なエコシステムが存在 (が前提となって)いる。
ローコードは通常は教えてもらうことはない。というのはローコード製品の中身の知識は必要とされていないからである。その製品を制作した人達は、ツールは一般的な言語で書かれていることと指摘するが、実際には製品開発者にとってはそれだけの挑戦でできている訳ではない。(ローコード製品を制作するという)その挑戦には、ローコードフレームワークに組み上げる追加の構造が必要となる。その部分こそが(製品価格として)支払いに値する部分であって、開発チームとしては、もしプラットフォームを修正したり拡張したりしようとすれば、時間をかけて学習する必要がある。
>Top 1-9. Low-code frustration #9:
- You’re locked in:
Sometimes starting up one of these low-code platforms feels like joining the mob. It’s easy to join but hard to leave. The price for doing less work and standing on the shoulders of giants is that you become beholden to the giants. If the giants move, you move with them. If the giants stop moving, or collapse, you’re in trouble. ❏
1-9. ローコードへの失望 #9:
- ロックインされた状態:
ローコードプラットフォームの一つを開始することは、群衆に加わるようなものである。参加するのは容易だが、そこから抜け出すのは大変である。省力化によって実現される安価な価格は、（ローコード製品開発者という）巨人の肩に乗っていることを意味し、それはその巨人に捕まっていることでもある。もしその巨人が動けば、あなたも一緒に動く。もし巨人が止まったり、崩れれば、あなたもそのトラブルに見舞われるのだ。 ❑
>Top 2. Low Code Development is on the Rise:
by Elizabeth Wallace, RTInsights.com, Dec 7, 2020
- Source: https://www.rtinsights.com/low-code-development-is-on-the-rise/
- The cloud app service hasn't just made it easier to deploy other people's software, it's made it easier to build your own, too. We test 10 top players in the low-code development space where custom app creation is easy and knowing how to code is optional. (By Rob Marvin, updated Aug 10, 2018)
- Low-code platforms are on the rise, and with projected revenue of USD180.7 billion over the next ten years, it’s one of the hottest tech trends emerging in the wake of digital transformation. Let’s take a look at what’s contributing to low-code platform popularity and what businesses can expect from its use.
2 . ローコード開発は伸長している。：
Elizabeth Wallace, RTInsighet.com記事 (2020/12/7)
- 原文：左記
- クラウドアプリのサービスは、他人が作ったソフトウェアを展開するのは容易にしただけでなく、自作のソフトウェアを構築するのも容易にした。ローコード開発分野で10件のソフトについて、カスタムアプリを作るのが容易か、またコーディングがオプションであることをどのようにして理解できるかの点についてを検証してみた。(Rob Marvin; 2018/8/1)
- ローコードプラットフォームは現在人気沸騰中であり、今後10年間でUSD1807億もの売上規模が予想され、DXへの潮流を受けて、ハイテク分野では最も熱い視線を浴びている。このローコードプラットフォームの人気の秘密に加えて、この利用でどのようなビジネス展開が期待できるか見てみよう。
>Top 2-1. What are low-code platforms?:
- In the recent past, developing tech products required the expertise of a professional developer or IT team. Departments wishing to customize certain tech products were subject to third-party or departmental availability, creating wait times and lag in deployment.
With data-heavy business operations, the wait is unsustainable. Non-IT departments need customized solutions that gather, analyze, and deploy data. Without these products, companies risk falling behind competitors.
( See also: How No-Code Platforms Are Helping SMBs Go Fully Digital)
The problem is that sales teams aren’t typically coders, and neither are other departments vital to revenue and growth. Low-code products provide the type of accessibility these teams need to build and deploy tech products to drive innovation without waiting for a solution from IT.
Low-code platforms use drag and drop components containing the building blocks of programming, removing the need for technical expertise in development. Now, sales can create sales-specific dashboards, for example, that display data trends or analysis without IT intervention. It’s a new era of data literacy for business.
- The demand for low-code will only increase
Businesses can deliver value to customers through digital solutions using the team they already have. Quite a few industries have already used these platforms, including education, financial and insurance services, and healthcare.
North America is the biggest provider of low-code platforms, but that could also change. Demand is predicted to surge in the Asia-Pacific region thanks to rapid economic growth and smart-phone access.
As more organizations race to first in digital transformation, low-code platforms could cement their place in ordinary business operations. This dependence on technical solutions paves the way for their use. ❑
2-1. ローコードプラットフォームとは何か:
- 近年過去においては、ハイテク製品を開発するには、高度に専門的な開発者やITチームを必要としてきた。ハイテク製品をカスタマイズしようと思うと、サードパーティや部門内でそれができる人達がいることが条件であり、そのための待ち時間や人材確保に時間がかかることになった。多量なデータを伴うビジネス展開の場合は、その待ち時間は許されない。IT部門以外にとって、データを収集･分析･展開するためにカスタマイズしたソリューションが必要となり、そのため競合他社に遅れと取るリスクがでてきている。
("ノーコードプラットフォームはいかに中小企業のデジタル化に支援するか" の記事参照)
問題は、セールスチームは典型的にはプログラマーでなく、他の部門も売上と成長に関してそれほど真剣ではない。ローコード製品はこれらのチームが、IT部門によるソリューションを待つことなく、イノベーションをもたらすハイテク製品にアクセスすることが可能となる製品である。
ローコードプラットフォームは、ドラッグ＆ドロップの部品によってプログラミングの要素を組み合わせるようになっており、開発において専門的技術を必要としない。今や、セールス部署は、例えば、セールス専用のダッシュボードを作り、IT部門に頼ることなく表示されたデータの傾向や分析を示すことができる。それはビジネスにとってデータ•リテラシーの新たな時代の到来であると言える。
- ローコードへの要求は増加する一方である。
ビジネス分野では、顧客に対し、既存のチームを活用してデジタルソリューションを通じた価値をいかに顧客に届けるかが重要である。現状では、教育、金融、保険、医療などごく一部の産業しかこれらのプラットフォームを使っていない。
北米はローコードプラットフォームでは最大の市場となっているが、今後は変化が起きるかも知れない。アジア太平洋地域での急速な経済成長とスマートフォーンの普及してによって需要が急増する可能性があるからである。ますます多くの組織がDX競争に加わるので、ローコードプラットフォームは通常のビジネス展開でその利用が必須となるだろう。これに依存した技術的なソリューションがさらにローコード開発利用への道を拓くことになる。 ❑
>Top 3. How No-Code Platforms Are Helping SMB's Go Fully Digital: by Artem Ptashnik, RTInsights.com, Oct 26, 2020
- Source: https://www.rtinsights.com/how-no-code-platforms-are-helping-smbs-go-fully-digital/
- No-code tools put the power to create, organize, and automate business processes in the hands of non-engineers.
Welcome to the revolution – the no-code revolution, that is. No-code tools are popping up left and right, democratizing technology that was formerly only available to highly skilled engineers. You can now build a website or app, design a chatbot, automate tasks, open an online store, and much more, all without typing out a single line of code. This movement will forever change the way small and medium-sized businesses (SMBs) operate and grow digitally, and it’s only just begun.
No-code tools provide an easy way for SMBs to take their presence online and reach a new audience there. A brick-and-mortar store, for example, can start selling their products online more easily than ever before. Drag-and-drop interfaces for building eCommerce stores without code have become widely popular. That means shops of all sizes can digitize their operations quickly and easily.
- How no-code solutions work
Of course, no-code tools still involve code—it’s just all been set up and completed already, behind the scenes. As a result, the end-user of a no-code tool doesn’t have to know anything about coding. The engineers who built the platform have already done all the heavy lifting in terms of development. That means the user can simply drag and drop various elements in a visual, easy-to-use interface, and they’ll be ready to launch. They won’t be able to tailor the specifications of the end product as much as if they were coding it themselves, but most SMBs won’t need those advanced customizations.
3. ノーコードプラットフォームがいかに中小企業の全面的なデジタル化に寄与するか: by Artem Ptashnik (2020/10/26)
- 原文左記
- ノーコードツールは、非技術者に対して、ビジネスプロセスを作成し、組織化、自動化を図る上でパワーを与えることになる。
これがいわば革命、即ち、ノーコード革命である。ノーコードツールはあちらこちらで活用されており、従来は熟達した技術者でなければ使えなかった技術の民主化ともなっている。今や誰でも、コードを一行も書かないで、Webサイトを立ち上げ、 チャボット(Chat robot)を設計したり、作業を自動化したり、オンラインストアを開設したりすることなどが可能となる。この動きは、特に中小企業のデジタル活用の状況を決定的に変えることになり、それは正に始まったばかりである。
ノーコードツールは中小企業に対し、オンラインでの存在感を示し、それは新たな顧客を見出すことに通じる。例えば従来型の店舗でもその製品をオンラインで販売開始することが以前より容易に行うことができる。コードを作成しないでeコマースをドラッグ&ドロップだけで構築することが、広範な人気を集めている。どのような規模の店舗でも、その運用を迅速かつ用意にデジタル化できる。
- （"イノベーションの成功の秘訣"の記事参照 >以下に訳出）
- ノーコードソリューションはどのように動くのか。
当然ながらノーコードツールにもコードは含まれているが、それはコードが、背後で、予め装備されて完璧に装備された状態にあるからである。その結果、ノンコードツールのエンドユーザーは、コーディングに関する知識は不要となる。このプラットホームを作った技術者が、それを開発する段階で膨大なコードをすでに組み込んである。そのためユーザーは単に使い勝手の良い様々な要素をドラッグ&ドロップするだけで立ち上げることが可能となるのである。あたかも自分でコーディングする場合のように、最終製品の仕様を細かく調整する必要はなくなる。しかし、多くの中小企業にとっては、それほど精緻なカスタム化が必要ではないかも知れない。
>Top 3-1. How No-Code
- Key benefits of no-code tools for SMBs
- No-code tools put the power in the hands of non-engineers. That means CEOs, solopreneurs, marketers, and anyone in between can create, organize, and automate business products and tasks without ever learning to code. This translates into four key benefits for SMBs:
- #1. Low risk
Tools that don’t require coding mean users can test and iterate quickly, painlessly, and as often as needed. Instead of investing millions to hire a whole team to build a custom solution, SMBs can now build solutions themselves, quickly and cheaply. No-code platforms remove many barriers to entry for smaller organizations.
- #2. Low cost
A huge budget to finance a staff of engineers is no longer a necessity for businesses who want to go fully digital. Small teams and even entrepreneurs can use no-code technology to build out digital projects themselves. Plus, many no-code tools have freemium models. Start for free, experiment and validate your concept, and upgrade to scale when you’re ready. From there, most also have month-to-month subscriptions rather than long-term contracts. That’s why no-code tools are ideal for SMBs. They require a much smaller and more flexible investment than traditional programming methods, which were formerly only available to major organizations with big budgets.
- #3. Accessibility
The whole point of no-code solutions is to make certain digital tasks and projects accessible to everyone. So whether you’re creating a website or creating a chatbot, anyone on your team can take the reins on the project. From the initial build to tweaks down the line, whoever needs to be involved can participate easily with a minimal learning curve.
- #4. Agility
What happens if a business hires a team of engineers who spend months writing code for a project, and the end result isn’t quite right? The time and money required to go back to the drawing board isn’t something most SMBs can afford. In contrast, no-code platforms allow businesses to experiment and iterate on a dime. They allow for flexibility and optimization without the risk of wasting precious resources along the way.
3-1. 中小企業のためのノーコードツールのメリット::
- ノーコードツールは非エンジニアにも力を与える。このことは、CEO、個人事業主、販売員な誰にとってもコーディングを学ぶことなしにビジネス製品を制作し、組織化し、自動化できる。これは中小企業に以下のの４点で有利となる。
- ローリスク：
コーディングを必要としないツールとは、ユーザーがテストを実施したり、素早く簡単に必要に応じて繰り返し改善することができる。カスタムソリューションを構築するためのチームを作るために何百万ドルも投資する必要もなくなり、中小企業にとっては今や自分自身でソリューションを迅速安価に構築できる。ノーコードプラットホームは小規模企業にとって参入障壁を取り除いたのである。
- 低価格:
全面的にデジタル化を志向する企業にとって膨大な予算をかけて技術者を確保する必要がなくなった。少人数のチームあるいは起業家自身がノーコード技術を使ってデジタルプロジェクトを構築できる。さらにノーコードツールの多くはフリーミアム 【基本的なサービスは無料で提供し、高度な機能は有料とするビジネスモデル】のモデルとなっている。当初は、アイデアをタダで実験し評価してから、規模を拡大していけばよい。それからは、長期間の契約をするのではなく、月毎の契約でいける。これがノーコードツールが、中小企業にとって最適である理由である。それは、以前は予算が十分にある大企業だけが準備できた従来のプログラミングの方法より、ずっと少額で柔軟な投資で済むのである。
- 参加容易性:
デジタルの仕事やプロジェクトを構築する上でのノーコードソリューションの重要な点は誰にでも入手可能でる点が挙げられる。Webサイトやチャットボットを構築する場合、そのチームの誰かが責任者となってプロジェクトをリードしなければならない。当初の構築から実施面での微調整などで、誰でも容易に、ラーニングカーブを最小化できて参加できる。
- 迅速性:
技術者を雇ってコーディングに数ヶ月かかるような場合は、最終結果はどうなるのだろうか?そのための時間と費用を役員会に申請したとしても中小企業では賄いきれない。対照的にノーコードプラットホームの場合なら、実験したり、改善の繰り返しが僅かな金額で可能である。即ち、貴重な資源を浪費するktなく柔軟かつ最適に進めることができるである。
>Top 3-2. Tools for building something (websites, online stores, mobile apps):
- This type of no-code tool lets SMBs build something to create or improve their digital presence. Especially in the age of the COVID-19 pandemic, businesses can’t afford to not be available to customers online. No-code tools turn the process of setting up a digital store or website from a slow-moving, high-cost project to a task that can be completed by one person in hours or days.
- These types of tools are hugely beneficial to entrepreneurs and business owners who are just starting out or SMBs who want to experiment with new ideas. They can use them to build workable first versions of apps or websites fast, for little to no cost. That means they can have a real interface to test their ideas with a live audience.
- Tools for organizing something (data, lead information)
Data entry and handling eats up far too much time and far too many resources for lots of small- and medium-sized businesses. No-code platforms in this category make that a problem of the past. They let businesses sort, track, analyze, and collaborate on customer data, sales data, or any other type of information. When that data is more organized and accessible to team members, it becomes far easier to use it in meaningful ways that benefit the company’s bottom line.
- What no-code platforms can help SMBs achieve
- There’s a whole range of tools out there that don’t require coding. Most fall into one of these general categories:
- Tools for automating something (customer support, sales, communications)
Have you ever dreamed of having a few extra pairs of hands to take repetitive business tasks off your (or your team’s) plate? No-code tools for automation make this possible for a cost far lower than a new employee salary. Take tools that let people build chatbots without coding, for example. Once the bot is up and running, it can handle all kinds of tasks related to lead generation, lead qualification, customer service, product recommendations, and more—all on autopilot. It’s easy to see how useful a tool like this would be to any business, especially those with limited resources.
3-2. Webサイト、オンラインストア、モバイルアプリなどの構築ツール:
- ノーコードツールを使って中小企業が何かを制作したりデジタルでの存在感を改善することができる。特にコロナウイルスの時代には、顧客にオンラインで対応しないことは考えられない。ノーコードツールは、時間と費用のかかるデジタルストアやWebサイトの構築プロセスを、一人が数時間や数日で行って完成させることができる。
- これらのツールは、創業したばかりあるいは中小企業の起業家や事業主にとっては、新たなアイデアを実験する上で最大のメリットとなる。これらによって実際に動くアプリやWebサイトを迅速かつ安価に立ち上げることが可能になる。また実際の顧客に対して自身のアイデアをリアルインターフェースで実験するということが可能となる。
- データやリード情報などを組織化するツール:
中小企業の多くにとっては、データエントリーやその処理には、遥かに多くの時間や資源を必要とする。この分野のノーコードプラットホームは、これを過去の問題にしてしまった。顧客データや売上データなどどんなデータでも、整理し、追跡し、分析し、顧客と協業することができる。データがさらに組織化されチームメンバーで利用されるようになると、その情報を意味ある方法で活用し、会社の現場にとって役立つものになる。
- ノーコードプラットフォームは、中小企業アーカイブにとって何が役立つか
- コーディングを必要としないあらゆる種類のツールが取り揃っている。その多くは以下のような範疇に入る。
- 顧客、販売、コミュニケーションのサポートなどを自動化するツール群
あなたやあなたのチームにとって、繰り返し的な仕事を行う上で、もう数名の増員が欲しいと思ったことはあるのではないだろうか?ノーコードツールは、例えば、コーディングなしでチャットボットを構築したりできる。ボットが稼働するようになると、有望顧客の発掘、評価、顧客サービス、製品の推奨などに関連したあらゆるサービスを自動でしてくれる。このようなツールは、どのようなビジネスにとっても極めて有用であることが容易に分かるであろうし、しかもそれが限られた資源で可能になるのである。
>Top 3-3. The future is no-code:
- No-code tools are designed to be easy to use by anyone and everyone. They make building, organizing, and automating things simple and inexpensive, which gives SMBs more accessible growth resources than ever before. They create new avenues for exposure and success on digital channels that were previously out of reach for smaller organizations. Whether you’re starting or building a business, no-code platforms will help you go digital and achieve your goals with the skills, resources, and budget you already have. ❑
3-3. 未来はノーコードである。:
-
ノーコードツールは、誰にとっても使いやすいようにデザインされている。それは、構築、組織化、自動化を簡単かつ安価に行え、中小企業にとっては以前にも増して成長に結びつく資源を利用できることになる。以前には小規模企業にとっては到達できなかったデジタルチャンネルへの成功への新たな道を切り開くものである。ビジネスを創業する場合か構築する場合いずれでも、ノーコードプラットフォームはデジタル化を支援し、既存のスキル、資源、予算で目標を達成することができる。 ❑
>Top 4. 10 Best Low-Code Development Platforms in 2021, last updated: Jan. 10, 2021:
- Source: https://www.softwaretestinghelp.com/low-code-development-platforms/
- What is Low-Code Platform?:
Low-code development platform is an application that provides the Graphical User Interface for programming and thereby develops the code at a very fast rate & reduces the traditional programming efforts.
These tools help in the fast development of code by minimizing hand-coding efforts. These platforms not only help with coding but also with the quick setup and deployment.
- Working Of Low-code Development Platforms:
With these platforms, you don’t have to write the code line-by-line. It will allow you to draw a flowchart and the code will get created. Code-development gets faster with this method.
- Benefits of Low-code Development Tools:
Low code development tools provide many benefits and more people can contribute to the application development process. Also, these platforms help organizations in improving their agility. It reduces the complexity of the application development process.
Low code platforms have two other important benefits i.e. high productivity and decreased cost as it develops more applications in lesser time.
The following graph will explain the importance of low-code development tools. As per the research performed by frevvo, it accelerates the digital transformation at 69% and 40% it is responsible for reducing the dependency of high technical skills.
4. 2021年ローコード開発プラットホームベスト10 (2020/12/28更新)
- 原文左記
- ローコードプラットホームとは何か?
ローコード開発プラットフォームは、プログラミングでのGUIを提供し、それによってコーディングを非常に迅速に、従来のプログラミングの努力を軽減するアプリである。
これらのツールは、コーディングを手で行うことを最小化することで迅速な開発を支援する。これらのプラットフォームはコーディングの支援だけでなく、迅速な立ち上げと配備についても支援する。
- ローコード開発プラットフォームでの作業:
これらのプラットフォームの活用によって、コードを一行一行を書く必要ななくなる。あなたはフローチャートを描くだけでコードが生成されるのである。コード開発はこの方法でずっと迅速になる。
- ローコード開発ツールのメリット:
ローコード開発ツールには、多くのメリットがあり、多くの人々がこのアプリ開発のプロセスに関わっている。またこれらのプラットフォームは、組織の改善が迅速に行うのを支援する。それはアプリ開発プロセスの複雑性を減らすことになる。
それ以外にも、ローコードプラットホームには、２つの重要なメリットがある。即ち、より少ない時間でより多くのアプリを開発するという高い生産性と低コストの実現である。
以下のグラフは、ローコード開発ツールの重要性を示している。
【frevvoは、ワークフロー自動化ソフトのこと】 による調査にでは、DXへの推進を69%加速し、40%は、高度技術スキルへの依存を減少されることになった。
>Top 4-1. Reasons for Using Low-Code Platforms:
4-1. ローコードプラットフォームを利用する理由:
■デジタルイノベーションと変革を加速する。
■現状のITバックログを減少し、反応性を増加させる。
■レガシーによる負債を回避できる。
■技術スキル人材雇用に依存する難しさを減少させる。
■技術的な理由での他社への乗換えを防止する。
【churn (撹拌)とは、顧客が自社サービスから他社へ乗り換えること】
■内部プロセスの改善するために(IT部門に依存することなく)現場の人材を活用する。
【IT部門に属する技術者でなく、事業部門の現場担当者が自らシステムを開発して業務上の課題を解決すること。ローコード開発ではとくにCitizen developerと呼ぶ。】
■その他
>Top 4-2. Best 10 The Top Low-code Develoment Platforms: (#1-2)
- #1-2:
4-2. ベスト10 ローコード開発プラットフォーム: (#1〜2)
- １〜2位:
- 1: Monday.com "Monday": Win, Mac, iOS, Android対応; 小〜大企業向き、無料試用あり、費用USD8/月(但し、年間請求)
- 2: Visual LANSA "LANSA": Cloud, IBMi(=旧AS400), Win対応; 小･中･大企業向け; 無料試用あり;USD8.34/月
>Top 4-3. Best 10 The Top Low-code Develoment Platforms: (#3-5)
- #3-5:
4-3. ベスト10 ローコード開発プラットフォーム: (#3〜5)
- ３〜5位:
- 3: Creatio "Creatio": Win, Mac, Web対応; 中〜大企業向け; 14日間試用; 企業向け’USD25/月
- 4: GeneXus "GeneXus": Win, Mac, Linux, Web対応; 小･中･大企業向け; 無料試用あり; 創業社USD100/月、ソフトハウス会社USD250/月、企業向けUSD900/月
- 5: Zoho Creator "Creator"; Cloud, iOS, Android, PWA(モバイル用Web)対応; 小･中･大企業向け; 無料試用あり; USD10/月〜、Premium USD20/月、Ultimate USD35/月〜
>Top 4-4. Best 10 The Top Low-code Develoment Platforms: (#6-8)
- #6-8:
4-4. ベスト10 ローコード開発プラットフォーム: (#6〜8)
- ６〜８位:
- 6: Appian "Appian"; Cloud, Wind, Mac, Linux, UNIX, Solaris対応; 小･中･大企業向け; 試用あり; USD90/月
- 8. Kissflow "Kissflow"; Cloud, iOS, Android対応; 小･中･大企業向け; 試用あり; USD9/月
- 7: Mendix "Mx mendix": Web, Win, Linux Android, iOS, Win-phone対応; 中･大企業向け; Community版は無料; 単独 USD1875/月〜、プロ用 USD5375/月〜、企業用USD7825/月〜
>Top 4-5. Best 10 The Top Low-code Develoment Platforms: (#9-10)
- #9-10:
4-5. ベスト10 ローコード開発プラットフォーム: (#9〜10)
- 9〜10位:
- 9. OutSystems "Outsystems": Web, Win, Mac, Linux, iOS, Android対応; 中･大企業向け; 無料プランあり; USD6250/最初月〜USD15000/月
- 10. Salesforce Lightning "Saleforce": Web, Win, Mac対応; 小･中･大企業向け; 無料試用あり; USD25/開始月〜USD150/ 月
>Top 5. Features of Each Software: (#1)
- #1) Monday.com:
- Tagline: Quickly create apps for any business need
- monday.com Pricing: It offers a free trial. It has four pricing plans i.e. Basic (USD8/user/month), Standard (USD10/user/month), Pro (USD16/user/month), and Enterprise (Get a quote). All these prices are for annual billing.
- monday.com provides a low code development platform that will help you to digitize processes and workflows. It will increase employees’ productivity and engagement. It helps you with fast building the functionality as per your needs. You will be able to build any feature or functionality as per your requirement through this tool.
- The platform will let you automate the workflows without coding. It has features of interactive boards and custom forms that will provide business data in a quick and standardize way.
- It can be seamlessly integrated with your existing data and tools. It has more than 50 prebuilt adapters for that. You will also be able to integrate it with in-house built systems through an open API.
- Features:
- You will be able to streamline and modernize your workflows with the help of internal tools, custom workflows, automation & integrations, and data visualizations.
- You will be able to provide rapid application delivery through a lot of no-code building blocks.
- You will be able to visualize data in various ways, interactive, timeline, surveys, calendars, maps, charts, etc.
- Verdict: monday.com will empower your team with a no-code/low code development platform. The platform will let you create custom tools that are tailored for your team and develop new visualizations. It will streamline and modernize your workflows.
5. 各ソフトウェアの特徴: (#1)
- #1) Monday.com:
- 標語: どのようなビジネス用アプリも迅速に制作できる。
- monday.com価格: 無料試行あり。価格帯は４種類。ベシックは月USD8、スタンダード月USD10、プロ月USD16、エンタープライズ月は別途見積。これらの請求は年ベース。
- monday.comは、ローコード開発プラットフォームを提供し、プロセスとワークフローのデジタル化を支援する。それは、従業員の生産性と契約内容を高める。早期の機能構築が可能。このツールを通じて要求通りにどのような特徴･機能も構築できる。
- このプラットフォームは、コーディングなしにワークフローを自動生成できる。それは迅速にかつ標準的な方法生成する双方向の会議とカスタマイズした形式が特徴である。
- あなたの既存データとツールをシームレスに統合できる。そのための事前に用意された50のアダプタがある。それを貴社社内ですでに構築したシステムとのオープンAPIを通じた統合が可能である。
- 特徴:
- 内部のツール、カスタムワークフロー、自動化と統合化、及びデータ可視化によってワークフローを整理、最新化できる。
- 多くのノーコード部品を使って迅速なアプリの導入が可能
- データを双方向、スケジュール表、調査項目、カレンダー、地図、チャートなど様々な方法での可視化が可能
- 評価: monday.comは、ノーコードやローコードであなたのチームをエンパワーする。このプラットフォームは、あなたのチーム専用のカスタムツールを生成し、新たな可視化が可能となる。またワークフローの整理と最新化を行う。
>Top 5-2. Features of Each Software: (#2)
- #2) Visual LANSA:
- Tagline: Low Code >> High Control
- Visual LANSA Pricing: Visual LANSA has a three-tiered pricing structure i.e. Entry Level (USD16.66 user/month), Mid-tier (USD13.34 user/month), and Enterprise (USD8.34 user/month).
- LANSA’s low-code development platform accelerates and simplifies the creation of enterprise apps while making your development team more productive. LANSA puts you back in control.
- Features:
- Powerful low-code IDE to create desktop, web and mobile apps.
- Build apps faster, easier and at a lower cost than traditional methods.
- Extensive testing, deployment and integration controls.
- In use by several thousand companies around the world.
- Ability to write code inside the IDE.
- Only low-code to run on the IBMi, windows, and web.
- Verdict: Visual LANSA will allow professional developers to create applications much quicker than traditional coding and with an amount of control much higher than usually seen in low-code platforms.
5-2. 各ソフトウェアの特徴: (#2)
- #2) Visual LANSA:
- 標語: ローコード>>高度な管理
- Visual LANSAの価格: ３つの価格帯がある。各ユーザ当たりエントリーレベルは月USD16.66、中規模月USD13.34、エンタープライズ月USD8.34
- LANSAのローコード開発プラットフォームは、エンタープライズ用アプリの制作、また同時にあなたのチームの生産性向上を加速し容易化する。LANSAは、あなたの背後も管理する。
- 特徴:
- パワフルなローコードIDE (Integrated Development Environment, 統合開発環境)が、デスクトップ、Web、モバイルアプリを制作する。
- アプリを従来の方法よりも、早期、容易にかつ低コストで構築する。
- 広範なテスト、配置、統合管理
- 世界中で数千企業で使用中
- IDE内部でコードを書く能力
- IBMi、Widows, Webで動く唯一のローコード。
- 評価: Visual LANSAは、プロフェッショナルな開発者にとって、従来のコーディングに比べてずっと速くアプリの制作が可能。また普通のローコードプラットフォームよりずっと高度な管理ができる。
>Top 5-3. Features of Each Software: (#3)
- #3) Creatio:
- Tagline: Everyone can automate business ideas in minutes.
- Creatio Pricing: Studio Creatio, Enterprise Edition will cost you USD25 per user per month.
- Creatio is a low-code CRM and Process Automation platform. It offers a CRM solution for sales, marketing, and service. Studio Creatio will help IT as well as non-IT staff to easily build enterprise-grade apps and processes. It can be deployed in the cloud as well as on-premises.
- Creatio Marketplace has ready-to-use apps and solutions that will extend the platform functionality.
- Features:
- Creatio CRM is the platform with 360º customer view, lead management, opportunity management, product management, document flow automation, case management, Contact Center, and Analytics.
- It provides a leading UI for visual modeling.
- You will be able to build various types of apps through App wizard.
- It has features for security and administration.
- It provides features to streamline customer engagements and accelerate service delivery.
- Verdict: Creatio provides handy graphics and dashboards. Your routine operations will get accelerated with the use of this tool. It will help you to manage various types of cases and regulate timelines.
5-3. 各ソフトウェアの特徴: (#3)
- #3) Creatio:
- 標語: 誰もが、数分でビジネスアイデアを自動生成できる。
- Creatioの価格: Studio Creatio, エンタープライズ版月USD25・
- Creatioは、ローコードCRM及びプロセスオートメーションプラットフォーム。販売、マーケティング、及びサービス用CRMを生成する。Studio Creatioは、IT及び非ITスタッフが簡便にエンタープライズレベルのアプリやプロセスを構築できる。またそれをクラウドおよびオンプレミスで展開できる。
- Creatio Marketplaceは、プラットフォーム機能を拡張するアプリやソリューションを簡単で作成できる。
- 特徴:
- Creatio CRMは、360º顧客視点での見込客管理、機会管理、製品管理、文書フロー自動化、ケース管理、コンタクトセンター、及び分析のプラットフォームである。
- それはビジュアルモデリング用の先進的なユーザーインターフェースを提供する。
- アプリウイザードを利用して様々なタイプのアプリを構築できる。
- セキュリティ及び管理運営の特徴を備えている。
- 顧客との契約履行を合理化し、サービス提供を加速化する。
- 評価: Creatioは、使いやすいグラフィックスとダッシュボードを提供する。あなたの日常のオペレーションはこのツールに利用によって加速される。また様々なタイプのケースや予定時間の調整管理を支援する。
>Top 5-4. Features of Each Software: (#4)
- #4) GeneXus:
- Tagline: Software that makes software.
- GeneXus Pricing: Pricing per developer seat, independent of the number of apps created, or the number of end-users. A free trial is available for the product. Special plans for Startups (starting USD100/month), Independent Software Houses (starting USD250/month), and Enterprise (starting USD900/month).
- >Top Features:
- AI-based automatic software generation.
- Multi-Experience apps: Model once, generate for multiple platforms (responsive and progressive web apps, mobile native and hybrid apps, Apple Tv, chatbots & virtual assistants).
- Highest flexibility: The largest number of databases supported in the market. Interoperability capabilities for system integrations.
- Future-proof: Evolve systems over long periods of time and change between technologies and platforms automatically.
- Business Process Management Support: Digital Process Automation through integrated BPM modeling.
- Deployment flexibility: Deploy apps on-premises, in the cloud, or in hybrid scenarios.
- Application security module included.
- No runtime for generated applications, price by developer seat.
- Verdict: With over 30 years of experience, GeneXus provides a unique platform that captures the needs of users and generates applications for present and future technologies, without the need of learning each new technology. Allows pragmatic developers to evolve quickly, responding to market and technological changes in an agile way.
5-4. 各ソフトウェアの特徴: (#4)
- #4) GeneXus:
- 標語: ソフトウェアを作成するソフトウェア
- GeneXusの価格: 作成したアプリ数に関わりなく開発者の席数毎の価格、またはエンドユーザ数による価格。生成のフリー試行が可能。スタートアップ企業用特別価格 (月USD100から)、独立ソフトハウス用(月USD250から)、エンタープライズ用(月USD900から)
- 特徴:
- AIベースの自動ソフトウェア生成機能
- 多様なビジネス経験用アプリ: 一旦設計すれば、多様なプラットフォームに対応して生成する (Responsive WebアプリはPC/Tablet/スマホの画面幅に応じて最適配置するWeb画面、Progressive Webアプリ (PWA)はNativeアプリのようなリッチな画面、Nativeアプリは起動できるOSが限定、Hybridアプリはcross platformでのOSに対応、またApple TV、Chatbotや仮想環境への支援など）
- 高度な柔軟性: 市場で普及しているデータベースを最も多くサポート。システム統合での相互運用性がある。
- 将来性への保証: 長期間に亘って、また技術とプラットフォーム間の自動的な変更に対応して進化してきたシステム
- BPMをサポート: 統合的なBPMモデリングを通じ提供デジタルプロセスを自動生成する。
- 配置展開の柔軟性: オンプレミス、クラウド上、あるいはその混在場面での展開が可能
- アプリセキュリティモジュールを包含
- 生成アプリのランタイム版は無料、価格は開発者の席数
- 評価: 30年間以上の実績があるGeneXusは、ユーザニーズに対応し、かつ現在･未来の技術を見据えたアプリを、各々新たな技術を学ぶことなくユニークなプラットフォームを提供。実践的な開発者が迅速に進化して、市場や技術変化の早い時代に対応できるようにしている。
>Top 5-5. Features of Each Software: (#5)
- #5) Zoho Creator:
- Tagline: Build, Integrate, Extend.
- Zoho Creator‘s cross-platform app builder helps to build native mobile applications faster. Create apps on the web, publish and use them on your iOS and Android devices with multi-platform access.
- With over 7 million users worldwide and 6 million apps, our platform is powerful and flexible to adapt to your business needs. Zoho Creator has been featured in Gartner Magic Quadrant for Enterprise Low-Code Application Platforms (LCAP), 2020.
- Features:
- Create more applications with less effort.
- Connect your business data and collaborate across teams.
- Create insightful reports.
- Gain instant access to mobile apps.
- Uncompromising security.
- Verdict: Zoho Creator provides the low-code application development platform to build enterprise applications. It involves building applications with minimal coding which drastically reduces app-development time and effort.
5-5. 各ソフトウェアの特徴: (#5)
- #5) Zoho Creator:
- 標語: 生成し、統合し、拡張する。
- Zoho Creatorの価格: クロスプラットフォームアプリ作成ツールで、ネイティブなモバイルアプリをより速く制作すること支援する。Createアプリはクラウドサービスで、iOSやAndoroid上でマルチプラットフォームで使用可能。
- 世界中で、ユーザ数7百万、アプリ数6百万を達成したこのプラットフォームは強力であなたのビジネスニーズへの応用が柔軟にできる。Zoho Creatorは、2020年のガートナーの4象限でも、エンタープライズ用ローコードアプリプラットフォーム(LCAP)として評価されている。
- 特徴:
- 少ない努力で多くのアプリを開発できる。
- ビジネスデータを連携し、チーム間での協業する。
- 洞察力のあるレポートを生成する。
- モバイルアプリへの即時での対応が可能
- 妥協のないセキュティー対応
- 評価: Zoho Creatorは、エンタープライズアプリを制作するローコードアプリ開発プラットフォームを提供する。またコーディングを最小化することでアプリ開発ができるので開発時間と手間を節約できる。
>Top 5-6. Features of Each Software: (#6)
- #6) Appian:
- Tagline: Automate more codeless. Deliver powerful business applications, faster.
- Price: Appian will cost you USD90 per user per month for Standard Licensing. Get a quote for Application Licensing. A free trial is available for the product.
- Appian’s intelligent automation platform will help organizations to build smart applications that will improve the business, customer engagement, and worker efficiency. It will ensure you about the security of your critical applications.
- Features:
- Drag and Drop tools.
- It provides native AI services.
- It also offers no-code integration to AI/ML platforms through Google Cloud, Amazon AWS, and Microsoft Azure.
- Without writing any code, you will be able to integrate enterprise data, systems, and web services.
- Verdict: Verdict: Appian is the provider of the software development platform. The Appian low code development platform is a combination of intelligent automation and low-code development.
5-6. 各ソフトウェアの特徴: (#6)
- #6) Appian:
- 標語: さらにコードレスによる自動化。強力なビジネスアプリを早期に構築する。
- Appianの価格: スタンダード版は月USD90。アプリライセンスは見積を取得のこと。本製品のフリー試行版はある。
- Appianのインテリジエント･自動化プラットフォームは、ビジネスの改善、顧客関係、仕事効率化を改善するスマートなアプリの構築支援する。また重要アプリのセキュリティについても確実である。
- 特徴:
- ドラッグ&ドロップによるツール
- ネイティブAIサービスを提供
- Google Cloud,、Amazon AWS、及びMS Azureサービスを通じたAI/ML (Machine Language)プラットフォームへのノーコードでの統合を提供
- コードを書くことなしで、企業データ、システム、Webサービスを統合することが可能
- 評価: Appianはソフトウェア開発プラットフォームを提供する。Appianのローコード開発プラットフォームは、インテリジェント自動化とローコード開発の組合せである。
>Top 5-7. Features of Each Software: (#7)
- #7) KiSSFLOW - BPM & Workflow Software:
- Tagline: Automate Work. Reduce Chaos.
- Price: Standard Edition will cost you USD9 per user per month. A free trial is also available for this plan. The special pricing plan is available for education and non-profit organizations. You can also get a quote for bulk pricing (For more than 100 users).
- KiSSFLOW- BPM & Workflow Software will allow you to create custom Apps and automate business processes. It provides more than 45 pre-installed apps to create your own business applications.
- Features:
- It completely eliminates the need for coding.
- Drag and drop the facility to add and edit fields.
- Tasks and logic can also be built using the drag and drop facility.
- It will allow you to digitize your forms and requests.
- Verdict: It provides the cloud-based solution which can be used by businesses of any size and from any industry.
- Website: KiSSFLOW- BPM & Workflow Software
5-7. 各ソフトウェアの特徴: (#7)
- #7) KiSSFLOW - BPM & Workflowソフトウェア
- 標語: 自動生成で、混乱状態を減らす。
- 価格: スタンダード版は、月USD9。フリー試行版もある。教育用および非営利組織用には特別価格がある。100超の大口ユーザ向けには見積取得のこと。
- KissFLOW - BPM & Workflowソフトウェアは、カスタムアプリを制作およびビジネスプロセスの自動化を可能にする。また夫々のビジネスアプリ制作のために、既にインストール済アプリ45件以上を提供中。
- 特徴:
- コーディングの必要性を完全に除去
- ドラッグ&ドロップ機能を、編集領域に追加
- タスクおよびロジックもドラッグ&ドロップ機能を使って構築可能
- あなたのフォームや要求をデジタル化するのを支援
- 評価: クラウドベースソリューションで提供しており、どのような企業規模及びどの産業でも使用可能。
- Webサイト: 左記
>Top 5-8. Features of Each Software (#8):
- #8) Mendix:
- Tagline: Low-code Application Development platform.
- Price: Mendix prices are based on the number of app users. Its Community version is free. Mendix offers three more plans i.e. Single App (Starts at USD1875 per month), Pro (Starts at USD5375 per month), and Enterprise (Starts at USD7825 per month).
- Mendix provides the platform for building applications. It supports application development for any device. It has an option of private cloud, public cloud, and on-premises deployment. It also provides the facilities of automated backups and horizontal scaling with the Enterprise edition.
- Features:
- Agile project management.
- Visual modeling tools.
- Reusable components.
- Verdict: Mendix is a rapid application development platform with offline working capabilities. It is easy to adopt and is perfect for anyone.
- Website: Mendix
5-8. 各ソフトウェアの特徴: (#8)
- #8) Mendix:
- 標語: ローコードアプリ開発プラットフォーム
- Mendixの価格: アプリユーザ数に基づく。コミュニティ用はフリー。シングル用 (月USD1875から)、プロ用 (月USD5375から)、エンタープライズ用 (月USD5375から)
- Mendixは、アプリ構築用プラットフォームを提供する。あらゆるデバイス用アプリ開発を支援。プライベートクラウド、パブリッククラウド、オンプレミス用展開のオプションがある。エンタープライズ版では、自動バックアップ及び水平展開へ拡張する機能を提供する。
- 特徴:
- アジャイルプロジェクト管理
- ビジュアルモデリングツール
- 再利用可能コンポーネント
- 評価: Mendixは、オフライン作業用の超高速アップリ開発プラットフォームである。誰にも容易に適応でき完全に利用できる。
- Webサイト: 左記
>Top 5-9. Features of Each Software: (#9)
- #9) OutSystems:
- Tagline: Build Enterprise-Grade apps Fastly.
- Price: OutSystems offer a free plan which is free forever. There are two more plans i.e. Enterprise and Universal. Enterprise plan starts at USD6250 per month and the Universal plan starts at USD15000 per month.
- OutSystems will allow you to develop the applications at an unbeatable speed. It can be used for building Mobile Apps, Web Apps, and Enterprise-Grade applications.
- Features:
- You will experience error-free deployment for your apps, in cloud or on-premises.
- You can get real-time performance dashboards.
- You will be able to deliver scalable applications.
- Offers the latest security for your applications.
- Your applications could be integrated with any system.
- Verdict: It will be easier for developers to deliver the applications and editing those applications with OutSystems Rapid Application Development Platform.
- Website: OutSystems
5-9. 各ソフトウェアの特徴: (#9)
- #9) OutSystems:
- 標語: エンタープライズレベルのアプリを迅速に構築する。
- OutSystemsの価格: いつまでも利用可能なフリーなプランもある。またエンタープライズ用およびユニバーサル用に2つのプランがある。エンタープライズ用は、月USD6250から、またユニバーサル用は、月USD15000から。
- OutSystemsは、素晴らしく迅速でアプリ開発が可能になる。またモバイルアプリ、Webアプリ、エンタープライズグレードアプリの開発にも使用可能。
- 特徴:
- クラウド上でもオンプレミスでも失敗なく展開可能。
- リアルタイムでのパフォーマンス･ダッシュボードが制作できる。
- アプリの拡張性実現が可能
- アプリに関して最新のセキュリティを提供
- 作成するアプリは、どのようなシステムとの統合も可能
- 評価: OutSystemsのラピッドアプリ開発プラットフォームを使ってアプリを制作することで、開発者にとってはアプリの導入展開が容易。
- Webサイト: 左記
>Top 5-10. Features of Each Software: (#10)
- #10) Salesforce Lightning:
- Tagline: The future of Sales and CRM.
- Price: Salesforce Lightning platform has three pricing plans i.e. Lightning Platform Starter (USD25 per user per month), Lightning Platform Plus (USD100 per user per month), and Heroku Enterprise Starter (Get a quote).
- Salesforce Lightning provides the platform to build mobile apps with advanced security. Pro-Code tools will allow you to use any programming language for app creation. It offers features like embedding AI & IoT and integration with Salesforce & third-party data.
- Features:
- With No-Code builders, it will be easier to build mobile apps.
- Instant app creation from a spreadsheet.
- Lightning Process Builder will help you to build complex workflows.
- Verdict: Salesforce Lightning provides a suite of tools for building business apps. The platform will allow developers to build apps with a custom as well as standard components. It also provides features to accelerate the production process.
- Website: Salesforce Lightning
5-10. 各ソフトウェアの特徴: (#10)
- #10) Salesforce Lightning:
- 標語: 将来のセールスとCRM
- Salesforce Lightningの価格: 3種類ある。スターター版 (月USD25)、プラス版 (月USD100)、Herokuエンタープライズ･スターター版 (別途見積)
- Salesforce Lightrningは、先進のセキュリティを備えたモバイルアプリ制作のプラットフォームを提供する。Pro-Codeツールは、アプリ制作にはプログラミング必要となる。それはAIやIoTを備えてSalesforceや第三者のデータと統合するような場合に適用する。
- 特徴:
- ノーコード制作者にとっては、モバイルアプリ制作は容易。
- 表計算ソフトから即アプリ構築が可能。
- Lightning Proess Builderは、複雑なワークフローを構築するのに役立つ。
- 評価: Salesforce Lightningは、ビジネスアプリ構築用のツールセットである。そのプラットフォームは、開発者が、カスタムアプリおよび標準的なコンポーネントを構築するのを可能にする。またこれによって制作プロセスを加速化できる。
- Webサイト: 左記
>Top 5-11. Features of Each Software: (#11)
- #11) Microsoft PowerApps:
- Tagline: Apps that mean business.
- Price: PowerApps has two pricing plans. Plan 1 will cost you USD7 per user per month. The price for Plan 2 is USD40 per user per month. A free trial is also available.
- Microsoft PowerApps provides the platform to build the applications. Developers will be able to extend the app capabilities with pro-developer extensibility.
- Features:
- Point-and-click approach for app designing.
- Pre-defined templates.
- Easy connection of application to data.
- You will be able to develop web-based apps that will be compatible with iOS, Android, and Windows devices.
- Verdict: Microsoft provides the low code development platform through PowerApps. PowerApps is a powerful tool for building apps with a little complex UI. It is rich in features. It has features like cloud-based services integration, Workflow automation, App sharing, App running, etc.
- Website: Salesforce Lightning
5-11. 各ソフトウェアの特徴: (#11)
- #11) Microsoft PowerApps:
- 標語: ビジネスに特化するアプリ
- PowerAppsの価格: 2種類ある。プラン1は月USD7で、プラン2は月USD40である。また無料試用版もある。
- Micorosoft PowerAppsは、アプリを構築するためのプラットフォームを提供する。開発者にとっては、開発者に優しい拡張性をもつアプリへの拡張が可能となる。
- 特徴:
- アプリ設計ではポイント&クリックを用いる。
【Point-and-click: Mouse, Trackball, Touch pad, Pen tabletなどのpointing deviceを押して離す操作】
- 予め定義済みのテンプレートがある。
- アプリとデータとの連携が容易
- iOS、Android、およびWindowsデバイスと互換性のあるWebベースアプリの開発が可能
- 評価: Microsoftは、PowerAppsを通じてローコード開発プラットフォームを提供する。PowerApps は、少し複雑なUI上を持ったアプリを構築する上で、強力なツールである。様々な豊富な機能がある。クラウドベースのサービスとの統合、ワークフローの自動化、アプリ共有、アプリ実行など。
- Webサイト: 左記
>Top 5-12. Features of Each Software (#12):
- #12) AppSheet:
- Tagline: The Intelligent no-code platform.
- Price: AppSheet has three pricing plans i.e. Premium, Pro, and Business. Premium plan costs USD5 per active user per month. Pro plan costs USD10 per active user per month. You can get a quote for the Business plan. A free trial is available for the product.
- AppSheet provides the app maker for mobile apps. For apps building, many sample apps are provided like barcode scanner and offline access. You can start for free through Google Sheets and Excel.
- Features:
- This platform will help anyone to build apps.
- You will be able to develop and deploy multi-platform apps in real-time.
- You will be able to build the apps with features like GPS & maps, Image Capture, Signature Capture, and Barcode scanner.
- More features for building apps for Charts, email notifications, offline access, and adding your own brand.
- Verdict: The platform provides a good number of features for mobile app development and is easy to use.
- Website: AppSheet
5-12. 各ソフトウェアの特徴: (#12)
- #12) AppSheet:
- 標語: インテリジェント･ノーコードプラットフォーム
- AppSheetの価格: 3種類ある。アクティブユーザに対し。プレミア版は月USD5、プロ版は月USD10である。ビジネス版は別途見積。フリー試行版もある。
- AppSheetは、モバイル用のアプリ制作を提供する。アプリ構築用には、多くのサンプルアプリをバーコードやオフラインアクセスによって提供している。まずGoogle SheetsやExcelからフリーで開始できる。
- 特徴:
- このプラットフォームは、誰でもアプリ構築を支援する。
- 多様なプラットフォームアプリをリアルタイムで開発・展開できる。
- アプリ開発を、GPS&地図、イメージキャプチャー、署名キャプチャー、バーコードスキャナーのように構築することができる。
- チャート、電子メール通知、オフラインアクセス、ブランド追加のためのアプリ構築など多様な特徴を持つ。
- 評価:モバイルアプリ開発のために多くの特徴があり、また利用も簡単である。
- Webサイト: 左記
>Top 5-13. Features of Each Software: (#13)
- #13) Google App Maker:
- Note: The App Maker editor and user apps will be shut down on January 19, 2021
- Tagline: Business Apps your company needs, built by you.
- Price: Google App Maker is combined with G Suite Business and G Suite Enterprise. G Suite Business price starts at USD8.5 and G Suite Enterprise price starts at USD25.8.
- Google App Maker is a low code tool provided by Google. It can be used for building business apps. Just like other tools, it also has a drag-and-drop interface for building apps. It comes with G Suite Business. A free trial is also available for 14 days.
- Features:
- It provides templates.
- It has a drag-and-drop UI design facility.
- Declarative data modeling.
- Easy to connect with Gmail, Calendar, or sheets.
- Verdict: Google App Maker contain many functionalities like deployment logs, deployment settings, App preview, and data models. It is a web-based tool and also supports Windows and Mac OS.
5-13. 各ソフトウェアの特徴: (#13)
- #13) Google App Maker:
- 注: App Maker editorとユーザアプリは2021/1/19に閉鎖される。
- 標語: あなた開発するあなたの会社に必要なビジネスアプリ
- Google App Makerの価格: G Suite Business版とG Suite Enterprise版と同梱。G Suite Business版は、月USD8.5から、またG Suite Enterprise版は、月USD25.8から。
- Google App Makerは、Googleが提供するローコードツールである。それはビジネスアプリ構築に使用できる。他のツール同様、アプリ制作ではドラッグ&ドロップインターフェースを持つ。これはG Suite Business版と同梱である。フリーな試行版は、14日間利用可能。
- 特徴:
- テンプレートが提供される。
- ドラッグ&ドロップのUI設計ができる。
- 宣言型データモデリング
- Gmail、カレンダー、表計算ソフトとの連携が容易
- 評価: Google App Makerは、配置ログ、配置セッティング、アプリプレビュー、データモデルなど多くの機能がある。これはWebベーツのツールで、WindowsとMacOSをサポートする。
>Top 5-14. Features of Each Software (#14):
- #14) FileMaker:
- Tagline: Make your own app for any task.
- Price: For businesses, it offers price based on the number of users. For 5 to 9 users, it will cost you USD15 per user per month. For 10 to 24 users, it will cost you USD14 per user per month. For 25 to 49 users, it will cost you USD12 per user per month. For 50 to 99 users, it will cost you USD11 per user per month.
If you have more than 100 members in your team then get a quote for the pricing details. FileMaker Pro 17, which is for individuals will cost you USD540. A free trial is available for the product.
- FileMaker is an application development platform. It allows you to develop the app for any task. It can be deployed on-premises or in the cloud. It can be used on computers, iPad & iPhone, and through Web browsers.
- Features:
- The developed app will be compatible with mobiles, computers, the web, and the cloud.
- It has a streamlined user interface.
- You can copy and paste custom menus.
- It supports multiple email attachments.
- Verdict: It can be used by any type of business for creating custom apps. It is a flexible solution for app development.
- Website: FileMaker
5-14. 各ソフトウェアの特徴: (#14)
- #14) FileMaker:
- 標語: どのような仕事でも自分でアプリ開発しよう。
- 価格: ビジネス用には、ユーザ数に応じた価格設定がある。
5-9名用は月USD15、10-24名用は月USD14、25-49名用は月USD12、50-99用は月USD11である。ユーザ数100名の場合は別途見積。
FileMaker Pro 17は、個人用はUSD540で、フリー試用版あり。
- FileMakerは、アプリ開発プラットフォームである。どのよな仕事でもアプリの開発が可能。オンプレミス用、クラウド用での配置展開が可能。またPCの他iPad, iPhone, Webブラウザで利用可能。
- 特徴:
- モビル、PC、Web、クラウドいずれでも利用可能な開発アプリである。
- UIは整理されている。
- カスタムメニュをコピー&ペースト可能
- 多様な電子メール付属機能をサポートしている。
- 評価: カスタムアプリ制作のためにどのようなビジネスタイプにも利用可能である。アプリ開発のための柔軟なソリューションである。
- Webサイト: 左記
>Top 5-15. Features of Each Software:
- #15) DWKit:
- Tagline: Business processes, Workflow, and Forms in a self-hosted or cloud .NET Core solution.
- Price: DWKit will cost you USD11,000 for a perpetual license. No user charges.
- DWKit is a Digital Workflow Kit which will help you effectively manage form and business process development time with drag&drop interaction. Technically speaking, DWKit is a FormBuilder + Workflow + Security + Data Mapping.
- Features:
- Drag & Drop FormBuilder
- Full-featured Workflow Engine
- Fully customized End User Interface
- On-Premise Deployment
- Access to source code
- Verdict: DWKit offers a very interesting solution. You’ll get an efficient low code platform, yet with full capacity to modify this tool in your Visual Studio designer.
- DWKit is more complex to comprehend than other similar solutions and requires more than just an average developer’s skills, but its enhancement opportunities make up for it. It is the perfect tool for companies that are planning to build products of their own.
5-15. 各ソフトウェアの特徴
- #15) DWKit:
- 標語: ビジネスプロセス、ワークフロー、自社ホストまたはクラウド .NET Coreソリューション
- DWKitの価格: 永久版はUSD11,000。ユーザ側は無料。
- DWKitとは、Digital Workflow Kitで、ドラッグ&ドロップで帳票やビジネスプロセス開発の効果的な管理を支援。DWKitは、フォームビルダー+ワークフロー+セキュリティ+データマッピングからなる。
- 特徴:
- ドラッグ&ドロップのFormBuilder
- フル機能のワークフローエンジン
- フルカスタマイズされたエンドユーザインターフェース
- オンプレミス開発
- ソースコードへのアクセス
- 評価: DWKitは、非常に興味深いソリューションを提供する。効果的なローコードプラットフォームだけでなく、このツールをあなたのVisual Studio designerの中にモディファイすることができる。
- DWKitは、同様のソリューションより理解するにはより複雑であり、平均的な開発者スキルより多くを必要とするが、その高度な機能は役立つ。自社の製品を計画している企業にとっては完璧なツールである。
>Top 5-16. Additional Platforms to Consider: (#16 - #19)
- #16) Spring Boot:
- Spring Boot provides the platform for building production-grade Spring-based applications. You can easily create stand-alone applications with this platform.
It has features like the automatic configuration of Spring and third-party libraries. It allows embedding Tomcat, Jetty or Undertow without deploying WAR files.
- Website: Spring Boot
- #17) Pega Platform:
- Pega Platform is a visual-driven tool for building application. It provides features to quickly deliver apps. A free trial of 30 days is available for the product.
- Website: Pega Platform
- #19) VINYL:
- Zudy provides the no-code application development platform. It provides the benefits of accelerating application development, empowering developers, and mobility. Vinyl architecture has three layers i.e. Design Layer, Business Logic Layer, and Data Access Layer. These architectural layers provide a flexible environment to design and build.
- Website: VINYL
- #19) Ninox Database:
- Ninox provides the platform for building database applications. It provides the templates for databases like CRM, Inventory, Invoicing, and many others.
A free trial of 30 days is available for the product. Ninox has two pricing plans i.e. Ninox Cloud and Private Cloud. Ninox Cloud price starts at USD8.33 per user per month. Private cloud price starts at USD16.66 per user per month.
- Website: Ninox Database
5-16. その他ソフトウェアの特徴: (#16〜#19)
- #16) Spring Boot:
- Spring Bootは、Springベースのアプリを構築するためのプラットフォームを提供する。このプラットフォームによってスタンドアロンアプリを容易に制作できる。これはSpringと第三者のライブラリーを自動連携する機能がある。また、WARファイルを配置しないでTomcat, JettyあるいはUndertowを埋め込むことが可能。
【WAR=Web application ARchiveで、Java EEアプリのパッケージ形式】
- Webサイト: 左記
- #17) Pega Platform:
- Pega Platformは、アプリ制作のためのビジュアル･ドリブンツールである。これはアプリの迅速な構築を可能にする。30日間のフリー試用版がある。
- Webサイト:左記
- #18) VINYL:
- Zudyは、ノーコードアプリ開発プラットフォームを提供している。これによって、アプリ開発、開発者能力増大、モビリティを加速できる。Vinylアーキテクチャは、３層から成っており、設計層、ビジネス論理層、データアクセス層である。これらのアーキテクチャ層によって設計および構築において柔軟な環境を提供している。
- Webサイト:左記
- #19) Ninox Database:
- Ninoxは、データベースアプリ構築のためのプラットフォームを提供する。これはCRM, 在庫、インボイス発行など多様なデータベースのためのテンプレートがある。30日間のフリー試用版がある。Nixoxの価格は、Ninox Cloud版とPrivate Cloud版がある。Ninox Cloud版は、月USD8.33で、Private Cloud版は月USD16.66である。
- Webサイト:左記
>Top 5-17. Conclusion:
- Appian low code development platform is the combination of intelligent automation and low-code development.
- KiSSFLOW is a cloud-based software for any industry and for businesses of any size.
- Mendix provides the application development platform with offline working capabilities.
- OutSystems provides the platform for developers to easily deliver and edit those applications.
- Salesforce Lightning is a suite of tools for developing business apps.
- Zoho Creator low code development platform can be used by non-developers and is perfect for building simple applications.
- Microsoft PowerApps is a rich in features low code development platform. AppSheet is best for building mobile apps.
- Google App Maker provides the low code development platform which is combined with G Suite Business and G Suite Enterprise.
- FileMaker is a flexible solution for any business type to build custom apps.
- (Hope this article will help you in selecting the right low code development platform. ) ❑
5-17. 各ソフトウェアの特徴
- Appianのローコードプラットフォームは、インテリジェント自動化
【Intelligent Automationは、RPA/AIを組合せたプロセス全体の自動化を実現する手法】とローコード開発との組合せである。
- KiSSFLOWは、企業規模、産業を問わず利用可能なクラウドベースソフトウェアである。
- Mendixは、オフライン作業を可能にするアプリ開発プラットフォームを提供する。
- OutSystemsは、開発者がアプリを容易に配置しそれらを編集することができるようなプラットフォームを提供する。
- Salesforce Lightningは、ビジネスアプリ開発のためのツールセットである。
- Zoho Creatorは、非開発者でも利用できるローコード開発プラットフォームで、簡単なアプリを構築するには最適である。
- Microsoft PowerAppsは、豊富な機能を有するローコード開発プラットフォームである。AppSheetはモバイルアプリを構築するには最適である。
- Google App Makerは、G Suite Business版やG Suite Enterprise banと同梱されたローコード開発プラットフォームを提供する。
- FileMakerは、カスタムアプリ構築する上でどのようなビジネスタイプにも柔軟なソリューションである。
- (この論文がローコード開発プラットフォームを正しく選択する上で参考になれば幸いである。) ❑
>Top 6. What's the Secret Formula for Innovation?:
by David Rosen, RTInsights.com, Apr 2, 2019
- Quote: https://www.rtinsights.com/whats-the-formula-for-innovation/
- What are best practices for fostering innovation culture? The recent boom in digital transformation efforts has produced some signposts to follow.
- “Innovate or Die” might be an apt catchphrase for post-millennium business, but that doesn’t make it a surefire path to success. A new documentary making the rounds at film festivals this year tells the tale of a largely forgotten Silicon Valley startup that was the epitome of innovative — and still failed miserably.
- >Top General Magic was a venture spun out of Apple in 1990 to develop a bleeding-edge handheld communications device. At the time, there were no digital cell phones, no Web, no WiFi, no 3G. The audacious company succeeded in assembling an alliance of telecommunications and electronics partners and it did release a product. But there was absolutely no market for it at the time and the venture petered to a lackluster end in 2002.
- While General Magic failed as a business, it was a hotbed for innovation that shaped the digital world as we know it today. Mobile “smart” computing, social media, apps and app stores, e-commerce, touchscreens, emoji, even USB…all sprung from the minds of its talent pool. Among other accomplishments, it’s alumni went on to found eBay, create Android, and eventually deliver the desired intelligent handheld communications device — now known as the iPhone.
- What’s most remarkable about the story is how far the company was ahead of its time. In a sense, the world was not yet ready for the technology General Magic dreamt up. It was just too innovative.
- >Top This stands in stark contrast to more conspicuous 21st century business failures, where thriving giants of industry have been eradicated by too little innovation (or too late). The past 20-odd years of increasing digitalization drove many once-familiar brands into obscurity under the juggernaut of disruption. We ‘ve seen Borders fall to Amazon, and Blockbuster to Netflix, through some combination of neglect in leadership or response to innovation-driven sea changes. And they weren’t alone.
- Since the year 2000, half of all Fortune 500 companies have gone bankrupt, been acquired, or fallen into obscurity while innovations redefine existing business models and forge others from thin air. Innovative technologies and/or methodologies now seem prerequisite for success, and digitalization plays a starring role.
- But there is no simple formula for accommodating “the new” or predetermining its importance in any particular business. Hungry startups still fail, and stable industries still get disrupted. So what is a business to do?
- >Top There are best practices for fostering a culture that supports innovation, including increasing collaboration across groups, creative hiring and talent development/compensation, and vigilant focus on “future proofing” products and services. Innovative cultures exhibit:
- Formation of short and long-term innovation-focused groups
- Wide-ranging and large-scale ideation
- Initial funding of initiatives (akin to seed rounds)
- Rapid prototyping
- Review, prioritization, and further funding
- Market introduction and piloting
- Fast iteration and refinement
- Ongoing structured evaluation of programs and quantification of KPIs
- Phases of additional investment based on known thresholds of success
- Factors that influence how this discipline is exercised include:
- Industry Readiness: What are the structural aspects of any industry that make it most susceptible to disruptive innovation? This is largely a digital transformation issue, but it is pretty obvious how innovation connects. Internet innovation, followed by mobile, cloud, and social, have largely driven this century’s business changes, but not every industry evolves at the same pace.
- Inherent Advantages: New or “digital native” entrants to markets are generally nimble and don’t have to unlearn outdated habits or service legacy, while incumbents often have a number of advantages that actually increase their likelihood of success (existing customers, channels, data, relationships).
- Positioning: This will include financial components that apply to the aforementioned portfolio theory and resource priorities, but also other gauges such as competitive advantage, differentiation, customer satisfaction/loyalty and employee satisfaction/retention.
- How is successful innovation viewed and measured? There are several good indicators, including:
- Advancing the organization’s critical capabilities (Can you do more?)
- Value chain disruption (Did you change the way that business is done?)
- Customer impact (Did you change how your customers engage?)
- Operational disruption (Did you improve internal execution?)
- Employee satisfaction (Do valued employees want to stay?)
- General “Innovative Traits” (Is the organization getting new products to market more quickly?)
- The venture capital approach for measuring success would look at quantitative measures of return-on-investment. Others may also look to revenue and profitability that is logical and unassailable, and still others look to sustainability by examining the margins from new products and services, essentially asking if the innovation is generating revenue and whether that revenue is “better” than what it’s replaced. ❑
6. イノベーション成功への公式とは何か?:
David Rosen, RTInsights.com, 2019/4/2
- 原文左記
- イノベーション文化を育成するベストプラクティスは何か? 最近のDXへの努力への高まりは、以下の手掛かりを与えてくれる。
- "イノベーションかさもなくば死か"は、おそらく2000年以降のビジネスのキャッチフレーズとなっているが、必ずしも成功への道筋が示されている訳ではない。今年(2019)の映画祭でも何回も新たなドキュメンタリーが発表されているが、その多くはイノベーションの権化だったシリコンバレーの忘れられたスタートアップ企業の物語であり、それはいまでも悲惨な失敗例となっている。
- General Magic社【Apple子会社としてBill Atkinsonや、後にAndroidを創業するAndy Rubin等も1990年設立時のメンバー。AT&T、松下、NTT、SONY等、後にMicrosoftも出資し、OSとしてMagic Cap, 通信用script言語のTelescriptを開発した】は、1990年にAppleからスピンアウトしたベンチャー企業で、携帯用通信端末の開発を行ったが、結果は出血投資(bleeding edge)となった。【Bleeding edgeとは、大きな発展が見込まれるが、ハード･ソフトの信頼性が低く、出血するリスクという意味で、leading edgeに対する比喩的表現】当時は、携帯電話、Web、WiFi、3Gもなかった時代である。この大胆な企業は通信会社やエレクトロニクス会社と連携して、製品の生産には成功はした。しかし、当時はまだ市場がなかったので、2002年に惨めにも消滅してしまった。
- General Magicは、ビジネスとしては失敗したけれど、今日我々が目にするデジタル世界を形作るイノベーションの温床となった。モバイルスマートコンピューティング、SNS、多くのアプリやアップルストア、eコマース、タッチスクリーン、絵文字、USBでさえ、これらは全てタレントプールから生まれたものである。その他の成功事例では、eBay, Androidの制作、iPhoneとして知られるインテリジェント携帯通信端末の登場である。
- これ以外にさらに画期的な物語がある。それはその会社がいかに当時の時代に先行していたかである。ある意味で、世界はGeneral Magicが夢見たような技術はまだ準備できていなかった。あまりにもイノベイティブ過ぎたということなのか。
- このことは、21世紀に生じた巨大企業によるあまりにもイノベーションのなさか、あるいは遅すぎることによる失敗事例と比べると顕著な対比をなしている。過去20年余の高まるデジタル化によって、かつての馴染みのブランドが、巨大な混乱の渦の中に巻き込まれてしまった。Borders【米国で2番目の書店チェーン】はAmazonに、Blockbuster【米国のDVDレンタルチェーンや動画配信サービスを展開】はNetflixへと、それぞれリーダーシップの欠如やイノベーション環境の変化などで吸収されていった。これは彼等だけではない。
- (以下参照: いかにシステム化したイノベーションがDXを可能にするか) >以下訳文
- 2000年以降、Fortune 500社の半数は倒産、買収、消滅する一方で、イノベーションによって既存ビジネスモデルを再定義したり、希薄な空気のような状況から立ち上がった企業もある。イノベーション技術や方法論は今や成功への前提条件のように見え、またデジタル化が主役を演じている。
- しかし、"その新しいもの"を生み出すような、あるいは特定ビジネスでの重要性を事前に決定するような単純な公式は存在しない。ハングリーだけではスタートアップ企業は未だに失敗しているし、安定的な産業も混乱に陥っている。ビジネスとして何をなすべきかが問われている。
- イノベーションを支援する文化を育てるようなベストプラクティスは存在する。それはグループを超えて協業したり、有能人材を雇用したり、タレントを育成してそれに報いたり、また"将来を保証する"ような製品サービスへの集中などである。イノベイティブ文化とは以下である:
- 短期および長期のイノベーションに注力するグループの創生
- 広範で大きな発想
- イニシアティブ段階での初期投資【Seed round: 新規ビジネスのアイデア段階での資金調達。Incubator, Seed accelerator, Angel投資家など】
- ラピッドプロトタイピング
- レビュー、優先順位、さらなる資金調達
- 市場紹介とパイロット参入
- 迅速なイテレーションおよび精緻化
- 計画の継続的で構造的な評価とKPIの定量化
- 既知の成功土台の構築に基づく追加投資の段階
- この原則がいかに実行されるかに影響する要因としては以下:
- 業界側の準備: この破壊的なイノベーションを最も受けやすい業界の構造的な側面は何か?これは主にDXの課題であるが、イノベーションがどのように関わっているかは明確である。インターネットイノベーション、それに続くモバイル、クラウド、SNSなどは、世紀の変化を牽引してきたが、各々の産業は同じペースで進化してきた訳ではない。
- 時代固有の有利性: 新規あるいは"デジタル・ネイティブ"世代の新規参入者は、概して機敏で、時代遅れの習慣や古臭いサービスを学ぼうとはしない。一方で既存企業には、成功に導く多くの有利な点がある (既存顧客、取引チャネル、データ、顧客との関係性など):
- ポジショニング: これには前述のポートフォリオ理論とリソースの優先度に適用される財務的要素が含まれる。しかし、競争優位、差別化、顧客満足度や忠誠度、また従業員の満足度や定着率などの指標もある。
- 成功するイノベーションはどのように観察あるいは測定されるのか?以下のような良い指標がある。:
- 組織の重要な能力を進歩させる (もっとできることはないのか?)
- バリューチェーンの崩壊 (ビジネスのやり方を変えたのか?)
- 顧客への影響 (顧客との関係を変えたのか?)
- 運用の崩壊 (社内での実施方法を改善したのか?)
- 従業員の満足度 (価値ある従業員はもっと定着したがっているか?)
- 一般的な"イノベイティブな特徴" (その組織は新製品をさらに早く市場投入しているか?)
- 成功を測るためのベンチャーキャピタルのアプローチでは、投資利益率を定量的に見ている。別の人は、論理的で揺るぎない指標である売上高と利益率に注目している。また別の人は新規製品サービスからのマージンを調査することで持続可能性に注目している。結局は、そのイノベーションが収益を生み出しているのか、またそのイノベーションが置き換えたものより優れているかどうかに着目しているということである。 ❑
>Top 7. How Systemized Innovation Enables Digital Transformation: by Alan Glickenhouse, RTInsights.com, Mar 13, 2019
- Quote: https://www.rtinsights.com/how-systemized-innovation-enables-digital-transformation/
- To win new business, companies are leveraging digital innovation to try innovative new offerings, new business models, and partnership ecosystems:
- We are in a battle for the customer… as we always have been. But, the new state of the art “weaponry” to win this battle is “Digital Transformation.” What is digital transformation? The Agile Elephant defines it as, “the process of shifting your organization from a legacy approach to new ways of working and thinking using digital, social, mobile and emerging technologies.
- It involves a change in leadership, different thinking, the encouragement of innovation and new business models, incorporating digitization of assets and an increased use of technology to improve the experience of your organization’s employees, customers, suppliers, partners and stakeholders.”
- This definition hits on many important points most around how a business needs to change, but it closes with the critical aspect that differentiates digital transformation – an audience centric (i.e. customer, partner, employee) view/experience. Historically businesses focused on the offerings they brought to market. Perhaps this alone is what a client wants. But, maybe it is only a part of the desired customer solution.
- For example, airlines advertise their flights and try to provide the best air travel option for a traveler. Is this all the client was looking for? Maybe. But, they might also be looking for transportation to/from the airport, a place to stay, a car rental, and depending on the type of travel – vacation activities, restaurants, etc. Delivering on the client perspective and not just the company offering is the digital transformation differentiator.
- >Top To win the client’s business, companies are looking for rapid time to market to try innovative new offerings, new business models, and creating partnership ecosystems. Traditional business planning and long-term delivery cycles are not going to cut it if the business is to be successful. Partner on-boarding cannot take months for each individual partner to develop a working customer-centric ecosystem.
- And, trying a new idea cannot require significant time and expense just to see if the offering is desirable. A far more agile method to enable innovation is required. Yet, we cannot expose our core business assets without proper security and controls to ensure reliability and availability. We must support rapid innovation while maintaining service levels for our core business functions.
- Business APIs and Microservices:
- For the last several years companies have been using Business APIs and Microservices to speed time to market and expand market reach.
- >Top Let’s start with defining these terms:
- Business API – is a simple to understand programmable interface focused on business recognizable assets – a product, an order, a customer, etc. Business APIs are targeted toward the consumer of the API, not the provider application(s). APIs do not contain business logic, they are an interface. APIs are focused on self-service consumption of the asset, simplicity, security, analytics, and speed to deliver.
- Microservices – a microservice contains business logic (i.e. code). Using microservices implies a micro component architectural style for creating applications. Instead of creating one large monolithic application that contains all the application parts in a single “package,” the purpose of microservices is to break the application into component parts, each providing a specific capability that together implement the functionality desired in the application. This approach increases agility, scalability, and improves DevOps.
- APIs and Microservices are frequently used together which has caused some confusion. Many have come to believe they are one and the same, but they are not. Please see “Clearing up misconceptions about APIs and Microservices” for more information on the positioning.
- APIs provide a level of abstraction from the implementation. Using an API allows IT to change the back-end system implementations without affecting the consumer (assuming the API interface remains compatible). A common scenario is to rearchitect monolithic applications using microservices and have the APIs which previously accessed the monolithic application or new APIs now access the microservice application.
- The new microservice application provides greater agility on the back-end and supports the ability to move appropriate components to the cloud. Enhancing agility and transition to cloud have been the two primary drivers for microservice initiatives.
- The modern view of Enterprise Systems of Record (SoR) is that they are composed of some microservice applications, some monolithic applications, some are on the cloud, some are on-premise, and some are provided by others (i.e. SaaS). The combination of APIs used by your systems of engagement (SoE) and partners accessing your modern SoR is the target architectural model for most enterprises today.
- With APIs and Microservices we provide improved agility. But what about innovation?
- >Top Innovation Tier:
- Most businesses are hesitant to add business logic to their critical core systems without significant effort to ensure they will not adversely affect the existing functionality, qualities of service, and security. Rightly so! Yet, part of the definition of digital transformation deals with encouraging innovation. We need a mechanism to support innovation without the time, cost, and risk associated with modifying core systems before proof that the innovation is a good idea.
- I propose a third business driver for microservice: innovation.
- Fig:
- As shown in the figure above, we have our existing SoR accessed via APIs from the SoE. Inserting the innovation tier allows a place to add new business logic without changing the back-end SoR systems. New microservices are developed for the innovation tier which access the existing SoR to obtain information and then provide the new business logic for the innovative offering we are testing. APIs are provided to consumers to access the new business logic to test our offering.
- >Top If our new offering is not successful, we simply throw away the new API and Microservice. Our investment was minimal, and we learned that the offering is not worth further investment. This is called “failing fast” – which is a good thing.
- If, however, we find the offering is successful we can now take the appropriate care to implement the innovation in our core systems while ensuring the existing qualities of services are not affected. By investing small efforts rapidly in the innovation tier we can test the market without the major time and expense that would previously have been required.
- So now we have a way to implement innovation rapidly, however accessing the new innovative offering is still a bit cumbersome. We need to create or change an API to invoke the new business logic, deploy the API, have someone consume it and deploy their update before we can test the new idea. Perhaps there is a better way?
- >Top Introducing a Service Mesh:
- The key benefit of breaking a monolithic application into microservice components is that each microservice is fully decoupled from the others. It can be maintained, or even replaced independently from the rest of the application. This is what enables the greater agility, scalability, and resilience benefits that microservices architectures promise. However, few microservice components are completely isolated. Most have a role that involves communication with other microservices in the application. This is where fragility can easily creep back into the application, reducing its agility and resilience.
- The industry has begun to standardize on container orchestration platforms such as Kubernetes to administer microservice components. Kubernetes provides basic functionality, for enabling discovery of other microservices at runtime and dynamic load balancing across replicated containers, but that is pretty much as far as it goes.
- It still is necessary to provide some of these inter-microservice communication capabilities in a way that is independent of the individual microservice components. This is where the service mesh (e.g. Istio) comes in. The mesh intercepts all intercommunication between microservices in a given scope (or application boundary). It can then introduce things such as routing, resilience and security patterns completely independently of the microservices themselves. Effectively, it extends the number of inter-connectivity patterns available to Kubernetes.
- Now let’s apply this to our prior scenario with the innovation tier. Instead of creating a new API with all the on-boarding and time required to deploy a new application, we can use an existing API (if there is one) that is related to the area of innovation. The API can pass the request to Istio for routing rather than directly calling the new microservice or old SoR function. Istio can choose where to route the request.
- >Top This allows for more dynamic routing which can provide additional real time data on how our innovation project is working. For example, if we want to try multiple different innovation options, Istio can route different percentages of the traffic to multiple different implementations (A/B testing). Or, we can implement the innovation for a small percentage of the traffic (canary testing) and then increase the usage as we see positive results or turn it off in the case of negative reaction. Each of these scenarios is implemented without changing the API or the business application microservices.
- In addition, Istio can also provide customer differentiation in testing new business models. API Management solutions use a “plan” to offer different amounts of API calls to consumers. A gold consumer may use the API more invocations per time unit than a silver or bronze consumer. A consumer signs up for a plan and the API gateway enforces the metric. This is also frequently used in direct monetization models to charge for higher usage levels. All of this is good functionality, but the concept of “plan” is only known to the API Management solution. Once the API invokes the microservices or other back-end systems these applications do not know anything about the plan of the consumer. What if we could pass the “plan” information onward – beyond the API Gateway? Now a gold customer might not only get more API calls, but also have priority on throughput, performance, or additional functionality provided by the called application. For a digital business we need to treat our best customers even better! Istio provides this capability for microservice clusters. In conjunction with API Management as an ingress, Istio can provide the prioritization outside the business application without changing the application itself and without over-deployment of resources. Higher priority customers can have their requests prioritized and/or routed to enhanced business functions.
- Earlier we also spoke about Digital transformation providing a customer-centric view. As a customer I find it frustrating when I must manually bridge internal company boundaries. A prime example is my insurance company where I have home, auto, and an umbrella insurance policy with the same company yet need to deal with the company as three separate entities, accessing and dealing with each policy separately.
- >Top Digital businesses do not have these boundaries, rather they use the data from their other LoBs and outside entities to make for a better experience for their customers, not letting the internal boundaries show through. Istio can assist in this scenario by routing requests to various microservices that supply different functionality for different LoBs.
- However, in this scenario APIs need to help Istio pull all this information together. While Istio does wonderful things for microservices within its scope of control, it does not handle anything outside that scope. Some of these resources may be within an Istio service mesh, but many may be in either other Istio clusters or in other systems such as other clouds, z/OS, SaaS applications, etc.
- To pull together information from these sources, Istio needs to invoke APIs to bridge between environments to gather the comprehensive customer view. Using integration between API management and Istio to provide appropriate security context to ensure privacy and data security is critical.
- Systemizing Innovation:
- Now for the biggest challenge – people! We need to change behavior. I have seen that when people are trying to accomplish something their first course of action is to use the method that they have successfully used before. The fact that there may be newer better methods is not an immediate consideration. So, if we implement all the IT changes that I have previously described and do not change the human behavior we will not succeed.
- >Top Our first step is to make it easy for innovators to take advantage of the new methodology and harder to go back to the prior time-consuming process. Our first step is to make it easy for innovators to take advantage of the new methodology and harder to go back to the prior time-consuming process. After enabling the IT environment for innovation, we need to execute education and communication tasks for our target innovator audiences. Set up lunch and learn sessions and demo how to introduce a new innovative scenario and provide a sandbox where the audience can try it. Provide metrics on the time it takes to use the new approach versus the historical options. And, put further roadblocks in the way of the historical options. Anyone involved in the previous process for approvals, provisioning, etc. for innovative projects should redirect requestors to the new methodology.
- Digital transformation success requires innovation. But, it is unlikely that every innovative idea should move forward to become a company offering. We want to encourage more innovation attempts – successful and not successful. The ability to innovate with rapid low-cost low-risk scenarios is a competitive differentiator. Creating a systemized approach to innovation where time and cost is minimal accelerates our digital transformation. ❑
7. いかにシステム化されたイノベーションがDXを可能にするか: by Alan Glickenhouse, TRInsights.com, 2019/3/13:
- 原文: 左記
- 新たなビジネスを勝ち取るためには、企業はデジタルイノベーションを活用して、イノベイティブな製品、新たなビジネスモデル、そしてパートナーシップ･エコシステムを構築しようとする。
- 我々は顧客獲得の競争をしており、それはいままでずっとそうだった。しかし、この闘いに勝利するすための最先端の"武器"として"Digital Transformation (DX)"がある。DXとは何か。The Agile Elephant誌の定義によれば、"あなたの組織をレガシー的なアプローチからデジタル、SNS、モバイルなど新技術を活用した新たな働き方や考え方へシフトしていく新たな方法"であるとしている。
- それは、リーダーシップや異なる考え方、イノベーションは新ビジネスモデルの追求、資産のデジタル化の促進、さらに組織の従業員、顧客、供給者、パートナー、ステイクホルダーの経験を改善するための技術をさらに活用することである。
- この定義は、ビジネスがどのように変化していくのかについて多くの重要な点を指摘している。しかし、それはDXを差別化する重要な点で終わってしまう。すなわち顧客、パートナー、従業員という観衆中心の見解や経験に終止してしまう。歴史的にはビジネスは市場に投入した製品に着目してきた。おそらくそれだけが顧客が求めるものだあるからだ。しかし、それは顧客が望むソリューションの一部分に過ぎない。
- Tata Consultancy: リアルタイムDXの継続について
- 例えば、航空会社は、旅行者に対して、フライト数を宣伝して、最善の旅行オプションを提供しようとする。これは顧客が求めている全てだろうか? おそらくはそうだろう。しかし、顧客は空港からの行き帰りの交通や宿泊先やレンタカー、また旅行の種類によっては、バケーションでの活動、レストランなども一緒に探したい。会社が提供するものだけではなく、顧客視点で提供することがDXの差別化につながる。
- 顧客のビジネスを獲得するには、会社は革新的な新しい提案、新しいビジネスモデル、パートナーシップエコシステムを作り上げるために、迅速にを市場投入することを求めている。伝統的なビジネス計画や長期のデリバリーサイクルは、もしそのビジネスが成功しているのであれば、カットすることにはならない。新たに参加した個々のパートナーは、顧客中心のエコシステムを稼働させるためにとして、その実現に何ヶ月もかけることはしない。
【on-boarding: 組織やサービスに新たな加入した人に早く慣れてもらい戦力化させる支援や研修】
- また、新たなアイデアを試すとしても、それほど時間と費用をかけることではなくて、その結果が望ましいかどうかを確認することである。だが、我々は、信頼性と有効性を確認するために、適切な安全性と管理もしないコアなビジネス資産を危険に晒すことはできない。我々は迅速なイノベーションは支持するが、同時にコアビジネス機能のサービスレベルも維持しなければならないのである。
- ビジネスAPIとマイクロサービス:
- 過去数年間、会社はビジネスAPIとマイクロサービスを使って、市場投入までの時間を早め、市場調査を拡大してきた。
- これらの用語を定義することから始めよう。
- ビジネスAPI:
ビジネスとして認識できる資産 (製品、注文、顧客など)に着目してプログラム可能なインターフェースを理解するという単純な仕組み。ビジネスAPIは、APIの消費者に向けているのであって、アプリの提供者に向けたものではない。APIにはビジネスロジックは含まれず、インターフェースに過ぎない。APIは、資産の自己消費、簡潔さ、セキュリティ、分析、デリバリー速度に着目したものである。
- マイクロサービス:
マイクロサービスにはビジネスロジック(code)が含まれる。マイクロサービスを使うことは、アプリを作成するためのマイクロコンポーネントのアーキテクチャスタイルを意味する。全てのアプリのパーツを一つのパッケージの中に包含する大きな一体型の（monolithic, 一枚岩のような）アプリをつくるのではなく、マイクロサービスの目的とするのは、アプリをその構成要素に分割して、特定の能力を与えて、アプリが必要とする機能を組合せていくやり方である。このアプローチは、迅速性、拡張性、またDevOps の改善につながる。【開発Developmentと運用Operationとが密接に連携した開発手法】
- API群とマイクロサービスはしばしば一緒に使われるが一部に混乱も生じている。多くの人の理解では、これらは一つのものではあるが、異なる点もある。さら詳しい情報としては、"APIとマイクロサービスについての誤解を解く"の記事を参照 >以下訳文
- APIは、サービス提供について抽象的な面を提供している。APIインターフェースを使うことで、IT部門がバックエンドシステムを変更する場合、その変更導入が消費者に影響を与えない(APIインターフェースは互換性を維持しているので)。よくあるシナリオとしては、一体型アプリをマイクロサービスを利用して再構築しようとする場合、一体型アプリにアクセスするのは、以前のAPIなのか、マイクロアプリにアクセルする新しいAPIなのかという場合である。
- 新しいマイクロサービスアプリは、バックエンドで遥かに迅速性があり、また適切なコンポーネントをクラウド上に移行することが可能となる。迅速性があることとクラウドへの移行が容易であることは、ミクロサービスを採用する２つの主な動機となる。
- 最近のSoR (Systems of Record)【記録保管を中心として社内基幹システム】は、一部はマイクロサービスのアプリ、一部は一体型のアプリ、そして一部はクラウド上、一部はオンプレミス、また一部は他社提供サービス(SaaS)で行われている。SoE (Systems of Engagement) 【顧客視点で顧客との繋がりを重視した情報系システム】と取引パートナーとが組み合せて使うAPIが、同時にSoRにもアクセスできるというのが今日最新の企業のアーキテクチャの目標となっている。
- APIとマイクロサービスの利用によって迅速性が改善する。ではイノベーションへの影響はどうだろうか?
- イノベーションのレベル:
- 多くのビジネスにとっては、中核的なシステムに新たなビジネスロジックを追加する場合、既存の機能に何か悪影響をあたえないか、サービスの品質やセキュリティは大丈夫かなど慎重に検討することになる。その通りである。しかしDXを進めることの一部は、いかにイノベーションを創生していくかに関わる。我々としては、イノベーションが確かに良いアイデアだと確信する前に、中核システムを変更することに関わる時間･費用･リスクを考慮しつつイノベーションを進めるメカニズムが必要となる。
- マイクロサービスをビジネスとして進める三番目の目的はイノベーションであると提案したい。
- 左図のように、我々はSoEからAPIを経由してアクセスする既存のSoRを持っている。このバックエンドのSoRシステムを変更することなく、新たなビジネスロジックを追加してイノベーション層を設置してみる。既存のSoRから情報を取り出して、テスト中のイノベーションを生み出す新たなビジネスロジックを追加してみる。これらのAPIは、新たなビジネスロジックをテストするために消費者にも提供されている。
- もし新たな試みがうまく行かない場合には、我々は単に新たなAPIとマイクロサービスをやめればよい。我々の投資は最小限で済むことになるとの、この試行は更に投資する価値がなくなる。これを我々は"failing fast"と呼び、それは実に良い考えである。【fail fast: 早く失敗を繰り返すことによって早期に上達することが可能という概念。特に新規分野の開拓では、スピードよく失敗を重ねることが重要】
- しかし、もしその試みがうまくいくとすれば、その時は我々は既存のサービスの品質に影響を与えないで、中核システムの中にイノベーションを起こす仕組みを慎重に導入することができる。このように少ない少ない投資で、イノベーション層を早急に導入して市場でのテストを行うことができる。この場合従来だったらもっと時間と費用がかかったと思われる。
- 今や、イノベーションを早期に起こす仕組みを得た訳だが、少し面倒なことがある。我々は新たなビジネスロジックを発動するにはAPIを新設あるいは変更する必要があり、そのAPIを導入して誰かにそれを使わせることになるが、それは我々が新たなイデアをテストする前に更新しなければならない。もっとよい方法があるだろうか?
- サービスメッシュの導入:
【Service mesh: Microservice毎にProxyを配置し、Proxy経由で他サービスと通信することで、Microservice間トラフィックを制御する。 このProxyはsidecarとも呼ばれ、個々のmicroservce間のロジックをcodingする必要ななくなる。またあるサービスが失敗した場合、service meshは、再試行し、成功までの時間データを集約することで、最適な待機時間などルールを作成できる。】
- 一体型アプリをマイクロサービスコンポーネントに分解することの主なメリットは、各マイクロサービスは他サービスから完全に分離していることである。そのマイクロサービスは維持･更新が他アプリとは独立して行うことができる。これによって迅速性、拡張性、回復容易性が確保できる。しかしマイクロサービスコンポーネントが完全に孤立している訳ではない。その多くは、アプリの中で、他のマイクロサービスとの通信を行う。このことがアプリの中に不安定要因が生じ、迅速性や回復容易性が減損し得ることになる。
- 【Container deployment: コンテナはVMと似ているがOSを共有できる分離特性がある。基盤のインフラが分離されているのでiteration開発が容易。KubernetesはOSSベスのコンテナ･プラットフォーム】
- 業界は、コンテナに関わるプラットフォームとしてKuberneteesとして標準化してマイクロサービスコンポーネントを管理できるようになった。Kubernetesは、基本機能の他、他コンテナとのruntimeでの認識やコンテンナ間の負荷バランス、その他のやりとりなどが可能となった。
- さらに各々のマイクロサービスコンポーネント間の独立の通信機能をもつ必要がある。そこでIstioというサービスメッシュが導入された。【Istio: Kubernetesより高度なルーティング機能を提供し、クラスタ外からのtrafic管理･監視などを行う。】
このIstioによって全てのマイクロサービス間の通信はアプリ領域内に留まる。また、これはルーティング、回復容易性、セキュリティなどをマイクロサービスとは独立して行う。それによって、内部の連結パターンの数を拡張してKubernetesに渡すことができる。
- このようにして、我々の当初のシナリオ通りイノベーション層を導入することができる。これだ新たなAPIを開発したり新たなアプリを配置したりしないで、我々は、イノベーション領域で既存のAPIを使うことができるようになった。APIは要求を出す場合、新たなマイクロサービスや古いSoR機能を呼び出すのではなく、Istioに渡してルーティングしてもらい、Istioは必要な場所へのルーティングを行う。
- これによってよりダイナミックなルーティングが可能となりイノベーション案件が必要とするリアルタイムのデータを提供できる。一例として、多くの異なるイノベーションの選択を試行する場合、Istioは多くの異なる装置に対し、(A/Bテストのように)異なる比率でルーティングすることができる。あるいは、少ない比率でのイノベーションの実験と行うことができる。【canary testing: 鉱山のカナリアから、まず小規模のテスト版でテストを行い、深刻なバグが発生しても被害を最小限で抑えられる。】もし結果が良好ならば、それから利用を拡大するか、または結果が良くなければ中止すればよい。いずれのシナリオの場合でもAPIやビジネスアプリのマイクロサービスの変更は不要である。
- さらに、Istioは、新たなビジネスモデルをテストする上で顧客の差別化が可能である。APIマネジメントでは、異なる数量のAPIをそれぞれ提供するか決められる。ゴールドレベルの顧客には、シルバーやブロンズの顧客より、多くのAPIコールを可能にするというようにである。顧客が参加するか、契約に応じて、APIのゲイトウェイはそれを振り分ける。これは高い利用顧客に対して料金差別化を図る方法でよく使われる。これは良い機能であるが、どの計画を選択したかは、API管理ソリューションだけが認知している。一旦、APIがマイクロサービスに対して発動すると、他のバックエンドシステムのアプリは、その顧客の計画については何も知らされないのである。もし顧客の計画がAPIゲイトウェイを超えて情報が伝達さえるとどうなるか?ゴールドの顧客はより多くのAPIコールをするだけでなく、スループット、パフォーマンスなど追加機能で優先権をもつ。デジタルビジネスでは、最良顧客には最良を提供する必要がある。Istioは、これをマイクロサービスクラスターに対して実行する。まず入口であるAPIマネジメントと連携して、Istioはビジネスアプリの外側でそのアプリを変更したり、リソースの過剰配置を行うことなく、優先権を発行する。高い優先権を持つ顧客は、自身の要求を優先させるか、または高度なビジネス機能のためにルーティングされるかどちらかになる。
- 前段階で、我々はDXが顧客中心を視点に展開されることを述べた。顧客として会社内部の壁を主導では橋渡しするのは不満である。例えば、保険会社の事例として、自宅に家、自動車、傘を同じ保険会社の保険に加入しているとする。その場合でも各々別の３つの保険契約として対応しなければならない。
- デジタルビジネスではこのような組織の壁は存在せず、【LoB=Line of Business 企業の事業部門】他の事業部門や外の機関からのデータを利用して、顧客対応を行い、内部の組織間の壁を意識させない。Istrioは、このような場合での要求を様々なマイクロサービスにルーティングして、異なる部門での異なる機能に向けて情報提供する。
- しかし、このような場合、API はIstioが全ての情報をまとめるのを支援する必要がある。Istrioは、その権限内でマイクロサービスに対しうまく機能するが、そのスコープの外側からは何もできない。一部のリソースはIstioのservice mesh の中にあるが、大部分は、他のIstioクラスターか、他システム(クラウド、z/OS, SaaSアプリなど)内にある。
- これらのリソースから情報を引き出すには、Istrioは APIを発動させて広い意味での顧客視点で、異なる環境間の橋渡しを行う。API 管理の統合を通じて、Istioは、プライバシーや機微なデータセキュリティに対し、適切なセキュリティ対応を行う。
- イノベーションをシステム化する。:
- 最大の課題は、人材である。我々は行動形態を変える必要がある。人々が何か最初の行動を起こす場合は、まず過去において成功したやり方を踏襲するのが通例である。そのことは、もっと良い方法があったとしても、直ぐには採用の対象にならないということである。従って、我々はITを変更する場合は、人間の行動もそれに応じて変えるということがなければ成功しない。
- まず第一段階として、イノベーターにとっては、新たな方法論を利用することが有利であり、それ以前の時間のかかる方法へ戻るのは大変なことだと認識させることである。イノベーションのためのIT環境が可能となったのちは、研修を実施し、イノベーターとなる目的の聴講者とのコミュニケーションをとる必要がある。ランチを設定し、会議で学習し、デモを行って新たなイノベーティブなシナリオを紹介し、聴講者が試行できるような【Sandbox: 保護された領域でプログラムを操作し、他のデータやシステムに影響が及ばないような安全な砂場のこと】練習環境を用意する。新たなやり方と従来のやり方とを比較して時間を測定する。またいままでのやり方での問題点も指摘する。また誰かがイノベイティブな案件に対応するために、以前のプロセスを踏襲して承認や提案など求めてきた場合は、突き返して新たな方法での再提出を要求する。
- DXの成功にはイノベーションが必要である。しかし全てのイノベイティブなアイデアは、会社の推進する所とはならない。我々はさらに成功や不成功に関わらず、イノベーションの試行を進める必要がある。迅速に低コスト・低リスクシナリオでのイノベーションを起こすことは競争上の差別化要因である。時間と費用最小化したイノベーションに対してシステム化したアプローチを行うことがDXを加速化することに通じる。❑
>Top 8. Clearing up misconceptjons about APIs and Microservices, by Alan Glickenhouse, IBM Middleware User Community, May 30, 2018:
- Original: https://community.ibm.com/community/user/middleware/blogs/alan-glickenhouse1/2018/05/30/clearing-up-misconceptions-about-apis-and-microservices
- Two extremely hot IT topics right now are APIs and Microservices. Unfortunately, too many people think this is one topic – i.e. they are the same thing. This is not correct. There are several misconceptions about APIs and Microservices, and throwing in Services (from Service Oriented Architecture - SOA) the confusion gets worse. So, I thought I would try to take a very simple view at positioning these.
- Common Misconceptions and Why:
<Misconception>
<Why do people think this?>
- Microservices are just more fine-grained (web) services
- The naming of microservices and services basically implies this
- APIs are microservices (and vice versa)
- APIs and microservices are frequently used together with one representing the other (more later), so they are often treated as one item
- APIs and Services are the same – API is just a new name for a Service
- Both an API and a Service are frequently implemented as REST or SOAP, so since the technology used in the implementation is the same, they must be the same.
- If you understand that these are misconceptions, then you can stop reading now.
- In writing the following definitions, I am going to stay away from technology. Instead I will use the purpose or principles that drive the use of the item. Technology changes frequently and can mislead as to why or where you should use a capability, but if you use the purpose to guide you then positioning becomes easier.
- API – Should be correctly referenced as a “Business API”. See “What is an API? and What is the API Economy?” for a more complete discussion. Summarizing: “Business APIs are simple to understand interfaces focused on business recognizable assets – a product, an order, a customer, etc. Business APIs are focused on self-service consumption of the asset, simplicity, security, analytics, and speed to deliver”. APIs should be fine grained and focused on what the target consumer of the API wants. If different consumers want different views of the asset, it is okay to have more than one API, each providing a specific view of the asset. APIs should not contain true business logic, since they are frequently deployed in the DMZ (in a gateway). There may be some transformation and routing logic included. The API will call the business logic or data assets either inside the enterprise Systems of Record and/or combine this with other calls inside or outside the enterprise to provide the desired result to the consumer.
- Service – perhaps one of the most overused words in all of IT. In this case I am referencing Service in the SOA sense. The purpose of a service is reuse and connectivity. A service is also an interface, representing an asset in the enterprise (hence confusion). But, in this case the purpose is to provide a single complete view of the asset. Typically, a service has a provider view. The “customer” service can provide any information about customers, “account” service about accounts, etc. Having a single view of the asset rather than have each project create their own definition removes duplication of information and out of sync issues. It also reduces costs since projects do not need to reinvest in creating the asset definition. Because of the completeness of the asset description by a service, this led to more complex coarse-grained interfaces that could meet many purposes.
- Microservice – a microservice contains business logic (i.e. code). It is not an interface, so clearly not identical to an API or Service as described above. Using microservices implies a micro component architectural style for creating applications. Instead of creating one large monolithic application that contains all the application parts in a single “package”, the purpose of microservices is to break the application into component parts, each providing a particular capability that together implement the functionality desired in the application. This approach increases agility, scalability, and improves DevOps. There are multiple definitions of microservices (here and here), which again causes some confusion and leads people to call many things microservices. Stick to the definition by purpose is my advice.
- Relationships
The picture below shows a monolithic application (left) which perhaps is being rewritten using a microservice architectural approach (right). Instead of a single silo component, the new version of the application is composed of three microservices.
- The original silo component application may have been represented by a single SOA service. That service has 4 APIs, each providing views that consumers want from the service/application. In the Microservice application note that we can still have the same 4 API views into the application. Since the API views are consumer oriented, the structure of the back-end application does not determine the number of APIs.
- Not all microservices need to be exposed through APIs. The following picture shows a microservice application. In some cases, there is an API exposed while in other cases other forms of application integration may be used to call the microservices directly.
- Individual microservice components should focus on their component functionality and not be burdened with the complexities of API exposure beyond the microservices application boundary. Exposure to a consumer (if desired) should be delegated to a separate capability (i.e. API Management) to enable consumption of the microservice functionality. API management components allow for control of the consumption of the microservice component assets:
- API Gateway:
- Decoupling/routing
- Traffic management
- Security
- Translation
- API Manager:
- Plan/product design
- Access management design
- Policy administration
- API Analytics:
- API usage
- Account (consumer) usage
- Developer portal:
- API discovery
- Self-subscription/administration ❑
8. APIsとMicroservicesに関する誤解の解消、by Alan Glickenhouse, IBM Middleware User Community, 2018/5/30:
- 原文左記
- ホットなITのトピックスとしてAPIとマイクロサービスがある。不幸なことに余りにも多くの人はこれを一つのこと、あるいは同じものと捉えれている。それは正しくない。APIとマイクロサービス、またSOAにおけるサービスについては若干誤解が生じている。以下その違いを要約してみる。
- 共通の誤解、なぜそれが生じるのか
<誤解>
<そう思われる理由>
- Microservicesは単に細かな(web) servicesである。
- microservicesやservicesという語感からそう思われる
- APIsとは、microservices (またはその逆)のことである。
- APIsとmicroservicesはよく一緒に使われので一体のものと思われがちである。
- APIsとServicesとは同じもの。APIは単なる一つのサービスの新しい名前である。
- APIもあるServiceもよくRESTまたはSOAPとして導入される。その導入時に使われる技術が同じなので、これらも同じものと思われる。
- 以上でこれらの誤解が解けたのなら、以下はスキップしてよいと思う。
- 以下の定義を記述するに当たって、少し技術から逸れるかも知れない。その代わり、これらが利用される目的や原則を述べたい。技術は頻繁に変化するので、それをなぜ、どこで用いるか誤解が生じるが、その利用目的がみ異界ならば位置づけは容易となろう。
- API: 正しくはBusiness APIと言うべきだが。 (詳しくは"APIとは何か、またAPI Economyとは何か"の記事参照) >訳文参照
端的に言えば、"Business APIとはビジネスが認識できる資産(即ち、製品、注文、顧客など) に着目したインターフェースである。" Business APIは、自動での資産の消費、簡潔さ、セキュリティ、分析、迅速なデリバリーに焦点を当てている。APIは、細かな規定されており、APIが必要とする目標の消費者を対象とする。もし異なる消費者がその資産を別の視点から必要とする場合は、APIは一つでたくより多く必要となり、各々が資産の個別に視点で対応する。APIは、正しいビジネスロジックを持っていないので、通常はGatewayの中のDMに設置される。そこにはある変換やルーティングロジックが含まれる。そのAPIは、企業のSoRの中にあるビジネスロジックやデータ資産をコールし、あるいはこれらを企業内外の他のコールと組合せて、消費者が除く結果を提供する。
- サービス: この用語はIT全般で余りにも多く使われる。この場合は、SOAで定義されるサービスということである。サービスの目的は再利用と接続性である。サービスとはインターフェースであり、企業内の資産を代表している (それゆえに用語の混乱を生じる)。しかし、この場合、サービスの目的は、資産を単一の完全な観察対象として提供することである。典型的には、あるサービスとは視点を提供することである。ここで"消費者"サービスとは、顧客に関する情報を提供することであり、"アカウント"サービスとはアカウントに関する情報を提供するという具合である。各々の案件がそれぞれ独自の定義があるというのではなく、資産に関する単一の視界を持つことで、情報の二重化や同期の問題をなくすことができる。またそれは、案件毎に新たな資産の定義を行うために再投資する必要もなくなるのでコスト削減になる。このようにあるサービスによって資産の完全な記述ができると、さらに複雑で大きなインターフェースができ、多くの目的に対応できることになる。
- マイクロサービス: マイクロサービスには、ビジネスロジック(即ちコード)が備わっている。それはインターフェースではないので、前述のAPIやサービスとは同じではない。マイクロサービスという用語を使うのは、アプリを作る際のマイクロコンポーネント(部品)というアーキテクチャ上のスタイルを意味するからである。すべてのアプリの部分を一つの大きなパッケージとして、 monolithic的な一体型のアプリとして包含するのではなくて、そのアプリを小さな部品に分解して、アプリで必要とされる機能を装備した個別能力を有するマイクロサービスに分解するのである。このアプローチによって、迅速性、拡張性、DevOpsの改善につながる。マイクロサービスについては多くの定義が存在する (左記引用参照) が、それらはまた混乱を生じ、人々は多くのものをマイクロサービスを呼ぶようになってしまう。以下の定義を念頭に入れて欲しい。
- 関係性
左図の左側の図は、一体型アプリを、右側はマイクロサービスを示している。一体型は一つんぼサイロから成っているのに対し、マイクロサービスによるアプリは３つの要素から成る。
- 元のサイロ型アプリは、単一のSOAサービスの代表である。そこには4つのAPIがあり、各々は消費者がサービス/アプリを通じて欲しい視点を提供する。一方、マイクロサービスアプリでは、ここでは4つのAPIがある。API視点は、あくまで顧客志向なので、バックエンドアプリの構造からAPIの数は決められない。
- 全てのマイクロサービスはAPIを通じて露出している訳ではない。左図はマイクロサービスアプリを示している。(ユーザが操作できるような)露出しているAPIもあれば、露出していなくてマイクロサービス間で直接コールし合うようなアプリの統合された隠れたAPIもある。
- 個々のマイクロサービスコンポーネントは、各々のコンポーネントの機能に特化しているのでマイクロサービスアプリの領域を超えてAPIを露出させることで生じる複雑性を回避している。(必要があれば) 消費者にAPIを露出させることになるは、それは別の機能を付与するということになり、(API Management) マイクロサービスをさらに消費することになる。API Managementは、マイクロサービスコンポーネントの資産管理は以下である。
- APIゲートウェイ:
- デカップリング/ルーティング
- トラフィック管理
- セキュリティ
- 翻訳
- APIマネジャー:
- 計画/製品設計
- アクセス管理設計
- ポリシー管理
- API分析:
- API利用
- アカウント(消費者の)利用
- 開発者用ポータル:
- API発見
- 自己記述/管理 ❑
>Top 9. What is an API? and What is API Economy? : by Alan Glickenhouse, IBM Middleware User Community, Jan 04, 2018:
- Businesses start to consider APIs and the API Economy at various times. Many are long down their API journeys, while others are still considering whether to start. With the beginning of the new year I thought it was an appropriate time to step back and take a look at some of the basics that companies considering APIs might want to know.
- What is API?
- API stands for Application Programming Interface. But, you already knew that. API is not a new term. It has been around for many decades. One program calls another program through its API. So, is there something new here? The new interest in APIs is not from this traditional definition. In fact, the correct term we should be defining when talking about this increased interest is “Business API” or “Web API”.
- Traditional APIs were often very technical complex interfaces to applications. They represented the complete functionality of the application being called and provided an input/output mechanism to obtain the results the program could provide.
- “Business APIs”, by contrast, are simple to understand interfaces focused on business recognizable assets – for example, a product, an order, a customer, etc. Business APIs are focused on providing a simple easy to consume interface targeted toward the consumer of the API, not the provider application(s). The target consumer for the business API is still a programmer. This programmer could be your own company employee, a partner company or anyone out in the public. It is your choice who you allow to consume your API. But, whoever this is, one of the goals is that they should be able to do this very easily through a self-service mechanism (called a developer portal).
- The term “web API” is also often used because many of these “business APIs” use web protocols. However, when thinking about “business APIs” in this new context it is better to think about this without reference to the underlying technical implementations. This gives much more flexibility as you move forward, because we all know that technology is always evolving.
- Most people reference this new definition simply as “API” leaving off the “business” or “web” modifier. Of course, this could lead to confusion as to whether you are referring to a traditional complex API or a Business API, so context may be required to sort this out.
- >Top What is the API Economy?
- “API Economy” is a general term related to the use of “business APIs” to positively affect the company. Frequently this is related to monetary benefits. In my blog series “API Economy – 4 Business Drivers and 7 Use Case Categories – Series Overview” I outlined several of the areas that are commonly targeted for API initiatives. The four business drivers: Speed to market, reaching new markets/customers, innovation (at low cost/risk), and improved sharing of assets across the enterprise (domains) are all very valuable scenarios for the use of APIs. Some of these may target internal programmers as API consumers to deliver offerings, projects, or capabilities to market quicker and with lower risk. Other scenarios may deal with easing the interaction between businesses to drive increased value for all the participants. Often this latter case is what is referenced as the “API Economy”, but I believe both internal and external scenarios are the correct definition.
- API Economy is also frequently related to API monetization. This is also an often misunderstood concept, and I refer you to my recent blog on this topic – “API Monetization – What Does It Really Mean?”.
- Is this a fad?
- We are starting to hear less about “APIs” and “API Economy” as these terms have now been around for several years. Is this a fad? Has the time for APIs come and gone? The simple answer is – Absolutely NO.
- New focus areas – Digital Transformation, Cloud computing (especially hybrid cloud), Cognitive computing (AI), Blockchain, IoT, Microservice architecture and many other new focus areas all use Business APIs. Business APIs have become the de facto interface for these new initiatives that are moving forward as use case examples where APIs provide the consumption and security context around the assets being exposed.
- Business APIs and API Economy are now passed the hype stage. Real projects are being implemented, industry ecosystems are being formed, and in some cases regulatory requirements and industry standards are being developed around Business APIs. If you are newly considering an API initiative, the time is now to get started. You are late. Not having Business APIs as we move forward will be like not having a web site in the late 1990s.
9. APIとは何か、API Economyとは何か: by Alan Glickenhouse, IBM Middleware User Community, 2018/1/4:
- ビジネスは様々な場面で、APIとAPI Economyとを考慮してからビジネスを開始する。多くの場合は、APIをどうしたものが長い検討を行い、一方では、いつビジネスを開始すべきかいつまでも検討している場合もある。新年でもあるので、幾つかの基本的な考えと会社がAPIをどう理解しようとしているかを述べる。
- APIとは何か?
- APIとは、Application Progaramming Interfaceの略である。このことはすでに周知で、APIは特に新しい用語ではない。それは何十年にも亘って使われてきた。あるプログラムは、APIを通じて他のプロセスを呼び出す(call)する。そのことは特段新しいことではない。新しいこととは、このAPIが、従来の定義とは異なる使い方がされていることである。これは"Business API"あるいは"Web API"と呼ばれて今注目されている。
- 伝統的なAPIは、アプリに対して技術的に複雑なインターフェースであった。それはアプリによる完全な機能をコールして、そのプログラムが出す結果を、出入力するメカニズムを提供していた。
- "Business API"は、それとは異なり、ビジネス上で認識される資産、例えば、製品、注文、顧客などに着目したインターフェースと理解すればよい。Business APIは、消費者のAPIに対して簡単なインターフェースとして、わかりやすく提供することに注力している。この場合、対象となる消費者とは、まだこの段階ではプログラマーである。このプログラマーは会社の従業員の場合もあれば、パートナー企業など外側の人間かも知れない。誰がこのAPIを消費(操作)できるかという選択の問題になってくる。しかし誰であれ、自己サービスメカニズム(開発者ポートタルと呼ぶ) を通じて、容易に操作できるようにするのがその目的である。
- ”Web API”という用語も、多くの"business API"のWeb上にあるのでこのように言われる。しかし、"business API"について検討する場合、あまり技術的な設定を意識しない方がよい。技術は常に進化しているので、そう考えることで前に進む柔軟性が得られるのである。
- 多くの人は、この新たな定義を、"business"や"web"という修飾を外して、単に"API"と言ったりする。その場合、従来の複雑なAPIのことを言っているのか、Business APIのことなのか、混乱をきたすことになる。
- API Economyとは何か?
- "API Economy"とは、"business API" が会社に良い結果をもたらすので、こう呼ばれる。またこの用語はしばしば金銭的な収益に関連して使われる。(API Economy - ４つのビジネスドライバーと7つの事例分類 - シリーズ要約を参照。その論文で、APIイニシアティブとして目標とすべき分野を概説している。４つのビジネスドライバーとは、1) 迅速な市場参入、2) 新市場新顧客の開拓、3) 低コスト低リスクでのイノベーション、および4) 企業間での資産共用の改善であり、これらは全てAPIの利用によって価値を生み出すものである。これらの一部は、API消費者として社内のプログラマーの目標となって、製品やプロジェクトによって迅速かつ低リスクで市場参入を可能にしている。別のシナリオでは、ビジネス間の相互作用を容易化することで、それに関わる人達に価値を提供している。特にこの後段の場合を"API Economy"と呼ばれるが、実は、シナリオは社内でも社外でも通用する定義である。
- API Economyは、しばしばAPI monetization (現金化)と呼ばれる。このことがさらに誤解を生むことになる。この点以下のブログ ("API Monetization - その真に意味する所は")を参照。> 訳文
- これは一時的な流行か?:
- ここ数年では"API"あるいは"API Economy"があまり語られなくなったが、この用語は一時的流行なのだろうか? APIが話題とならなくなったのか。その答えはNo.である。
- 新たな用語、Digital Transformation (DX), Cloud computing (特にhybrid cloud)、Cognitive computing (AI)、ブロックチェーン、IoT、マイクロサービスアーキテクチャなどは、全てこのBusiness APIに注目している分野である。Business APIは、これらの新たな潮流でのデファクトインターフェースとなっている。そこでは開示されたAPIが消費者によって操作され、情報提供やセキュリティサービスなどを提供している。
- Business APIとAPI Economyは、今や大いに誇張される用語になった。実際のプロジェクトが稼働し、業界のエコシステムが作られ、状況によっては規制が行われ、業界標準が、これらBusiness APIの周辺に展開さえてきている。このAPI戦略を新たに検討しようとすれば、今まさにその時である。むしろ遅いかも知れない。Business APIを知らずして進むことは、Webサイトを知らずして1990年代後半に前に進むようなものである。
>Top 10. API Monetization - What does it really mean?:
by Alan Glickenhouse, IBM
MIddleware User Community, Oct 17, 2017:
- Every time I get into a conversation about API Monetization I feel like quoting from The Princess Bride, “I do not believe that word means what you think it means.” Many businesses are excited about APIs and the API Economy and have heard of a terrific opportunity for API Monetization. This is true, it just most likely isn’t what they think the opportunity is.
- Many that I talk to believe that API Monetization means, “charging for the use of your APIs”. The business will build APIs to access an asset and a third party will pay you per API call, or in groups of calls, to access the API(s). There are some use cases where this makes sense, but fewer than you would expect given the number of people that believe this to be the meaning of API Monetization. Using this definition is very limiting and will probably lead to disappointment in your API initiative.
- A better definition of API Monetization is “driving revenue using APIs”. There are many business models under this definition and charging per API call is only one of them. This definition is much broader and incorporates many additional business models to drive revenue.
- When does it make sense to charge per API call? The primary factor is that there is an audience that wants to pay for it. Just because you want to make money with APIs does not mean there is a buyer for your API product. But, there may be other business models for the API (as we will see) that may generate revenue and be attractive to a potential audience. Beyond that, the asset value needs to be relatively consistent such that each call to the API provides roughly equivalent value to the consumer and consumes roughly equivalent resources from the provider (you). Variations on this model might support a free level of low usage (freemium), or lesser functionality APIs versus higher functionality at a higher cost (tiered). These models do exist and my point is not that you should avoid them. Just use them when they are appropriate.
- Let’s look at some additional business models that might also drive revenue but don’t fit into the simple
- pay per API model.
- Transaction fee – as an example for a payment API you probably want to charge a percentage of the value of the payment, not just a flat fee per API call. This also applies to the value of the data or transactions executed in many other scenarios.
- Free – yes, I said Free. Why have a free API? To attract customers. Facebook’s Login API is free which is just one way that Facebook supports increasing its user community. This allows Facebook to charge advertisers through a separate set of APIs.
- Developer gets paid to use your APIs – Really! This scenario includes situations where the consuming developer is acting as your agent, selling your products or offerings. Your API usage payment to them is like a commission.
- Indirect – this is by far the most common scenario. In these scenarios, you use APIs to facilitate the on-boarding of partners to reach new customers and new markets or enable an internal project coming to market faster. You create a partnering relationship and financial reconciliation between the companies is not related to the API usage, the APIs are just a far simpler way to integrate to the partner.
- In many of these additional business models the value is in obtaining new customers or providing new channels to market to reach new customers. Obtaining customers is typically far more profitable in the long term. The challenge for many of these additional models is that it is more difficult to directly associate the revenue generated to the API initiative. The simplicity of paying per API and having the direct correlation is very tempting. But, forcing the wrong business model on the API for the simplicity of measuring its success will probably cause the API not to be successful.
- There is a huge opportunity in API Monetization – if you view this in the broader context. Having a limited view of API Monetization as only one model will cause you to force fit APIs into that model that are not appropriate. While the APIs might have been successful with an appropriate business model, they might fail because of the pricing model imposed.
- For a more complete view of API Monetization from a business perspective please download the white paper, “API Monetization Understanding Business Model Options”. The following diagram outlines the models described in this paper.
- The IBM API Connect product supports monetization. Please see the following blogs for a description of the API Monetization capabilities included in API Connect:
10. API Monetization - その真に意味するもの:
by Alan Glickenhouse, IBM Middleware User Community, 2017/10/17
- いつもAPI Monetizationについて話をするとき、The Princess Brideからの引用を思い出す。それは、"私は、その言葉があなたが考えるような意味で使っているとは信じない"という言葉である。多くのビジネスではAPIやAPI Economyについて、そしてさらにAPI Monetizationのすごい機会だ聞くと熱狂するのである。それは事実だが、それはまさに彼等が考える機会とはちょっと違う意味であるが。
- 多くの人は、私が、API Manetizationの意味を、"あなたのAPIに対する課金"という意味で話をしている信じている。ビジネスではAPIを資産へアクセスするために設定し、APIを通じて、あるいはグループコールの場合は、多くのAPIにアクセスすることで、第三者があたなに支払をするとなっている。このような事例もあるだろうが、これがAPI Monetization の意味であると信じている人はずっと少ない。この定義は、ずっと範囲が広くて、収益を上げるための多くの追加的なビジネスモデルを含んでいる。
- APIコールに対して課金することにそれほど意味があるだろうか? まずそのようなことに対して支払たいという消費者がいることが前提となる。あなたがAPIによって金儲けしたいからと言って、あなたのAPI製品に対する買い手がいるという訳ではない。別のビジネスモデルとして、収益を上げてかるその消費者にとって魅力的なAPIがあるのかという問題になる。そもそも、APIに対する一回のコールで消費者に提供する価値と、提供者(あなた)が消費するリソースの価値とはほぼ同じようなものである。ビジネスモデルには様々あって低いレベルの利用(freemium) で低いレベルの機能を提供するAPIもあれば、逆に高コストで (階層差別化）で高い機能を提供する場合もある。これらのモデルは現に存在しているが、ここのテーマとして、それを避けている訳ではない。それらはそれを使うことが、適切な場合はそうすれば良いと言うだけである。
- 更に収益を上げるような別のビジネスモデルを追加してみよう。
- APIの利用毎の支払モデル:
- 取引毎の課金:
支払APIの例として、APIコール毎に一定料金ではなく、支払金額のある%比率を課金する。これは他の多くの事例にあるように、データあるいは取引価格に対して適用される。
- フリー:
なぜフリーAPIがあるのか? それによって顧客を引きつけるからである。FacebookのログインAPIはフリーであり、Facebookは、そのユーザコミュニティが拡大することを支援しているという意味で一方向サービスである。
- API を使うことで開発者への支払:
これは実際に存在する。このシナリオとは、それを利用する開発者が代理人となり、あなたの製品･サービスを販売する。あなたのAPIの利用による支払は、口銭のようなものである。
- 間接的支払:
これははるかに一般的なシナリオである。これらのシナリオの中には、新規参加のパートナーへの利便性としてAPIを使いやすくして、新規顧客と新規市場を広げ、社内でのプロジェクトを早期に市場参入させることができる。またパートナーとの関係強化や会社間の資金調整は、APIの試用と関係はなく、APIは単にパートナーに統合するためにずっと簡単な方法に過ぎない。
- これら追加したビジネスモデルの価値は、新規顧客を獲得し、また新たなチャネルで市場参入して新たな顧客を開拓することである。顧客を獲得することは、長期的にはもっとも利益があがるのである。これら追加のモデルの多くの課題は、API戦略にもたらされる収益に直接関連することが難しいという面がある。APIによる支払の単純さと、直接の関連性を持つことは大変魅力的である。しかし、その成功を測定するという単純なことに対してAPIを設定することは、間違ったビジネスモデルで、おそらくAPIとして成功しないだろう。
- より広い文脈で見る意図、API Monetization には大きな機会が存在している。API Monetizationを狭い視点で見ると、それは、一つのモデルでのAPIを、適切でないモデルに無理して結びつけたことが原因であろう。方や適切なビジネスモデルで成功するAPIがある反面、価格モデルを押し付けたがゆえに失敗に終わるAPIもある。
- API Monetizationをビジネスの視点で、より詳しく分析した資料は以下URLからダウンロードできる。"ビジネスモデルのさまざまなオプションを理解するAPI Monetizaiton。以下はこの論文で記載されている各種モデルの一覧である。
- IBM API Connect製品はmonetizationをサポートしている。以下API Connectに含まれるAPI Monetaiationに関する記事参照
>Top 12: Acronym & Jargon: (用語集)
- 2FA=Two-factor authentication;
- 3GL=Third generation language;
- 4GL=Fourth generation language;
- AD=Active Directory;
- AI/ML: AIとその下位カテゴリであるML (Machine Learning); コンピュータにデータのパターンや構造を分析･解釈させ、人間の介在なしに学習･推論･判断する。
- AIMS=Application Infrastructure & Middleware Servicrs; アプリインフラ&Middlewareサービス市場
- Angular: Googleが2016年頃開発したJavaScript frameworkで、コンポーネントベース（.html/.css/.ts/.spec.tsの４ファイル構成）で設計されており、これだけで(ライブラリー等の追加なしで)Webフロントエンド開発ができるので人気がある。但し、Typescriptの知識は必須。; 三大JavaScript frameworkは、Angulara, React (Facebookが開発), Vuejs (AngularJS開発者が開発した軽量framework)である。
- B2E=Business to Employee;
- BFSI=Banking, Financial Services, & Insurance; 銀行、金融サービス、保険分野
- BP Orchestration: No-Code, Low-Code, iPaaSの活用で、on-premise, cloudサービスをend-to-endでつなぎ(Process auchestration)によって工数削減、業務効率につなげる。Finance組織や非定型業務の効率化は課題大。
- CI/CD=Continuous integration/Continuous delivery;
- Citizen Developer: IT部門やビジネス部門が積極的に禁止していないツールを使用して、業務アプリなどを作成する従業員。多忙なIT部門が解決するまで待つのではなく、現場で自身が関連するプロセスを調査し、その改善を積極的に行うことでビジネス目標を達成しようとする。社内ハッカソンや社内コンテストなどで、Citizen developerを発掘･評価することでイノベーションにつながる。
- Container deployment: コンテナはVMと似ているがOSを共有できる分離特性がある。基盤のインフラが分離されているのでiteration開発が容易; Container化によって、アプリ･ロジックと依存関係に集中でき、特定のSW Versionや構成を気にしないで、開発とデプロイが容易になる。; Cf: KubernetesはOSSベスのコンテナ･プラットフォーム
- Cross Industry, 業界横断;
- Customer Journey: 顧客が商品やブランドとの接点認知から、購入意欲を喚起し、勾配に至るまでを旅に例えるマーケティング用語
- CX=Customer Expereince, 顧客体験 (CSより広い概念; 商品サービスの金銭的･物質的な価値に加えて、商品の感情･満足感･効果を含むすべての価値; LTV=Life Time Valueにつながる);
- DevOps=Develpment & Operation (新機能+安定稼働の追求); 開発Developmentと運用Operationとが密接に連携した開発手法
- DMN=Decision Model and Notation;
- DR=Disater Recovery, 障害復旧 (cf: RPO=Recovery Point Objective, 目標復旧時点;
- Drupal: PHPで記述されたコンテンツ作成管理用のOSS Platformである。
- frevvo: ワークフロー自動化ソフトのこと
- RTO=Recovery Time Objective, 目標復旧時間);
- Glue code: 互換性のない部分同士を結合するためだけに働く接着剤的なコード
- GTM=Go To Market Strategy, 新製品投入のaction plan;
- HIPAA=Health Insurance Portability and Accountability Act;
- IDE=Integrated development environment; Incident Mangement, IT systemの正常に利用できない事象(故障だけでなく)への対応;
- iBPMS=Intelligent BPM Suites; 定型のみならず非定形業務･SNSへの対応を含めた拡張BPM
- iPaaS=Integration Platform as a Service; 個々の業務プロセスやデータをEnd-to-Endでデジタルにつなぐことで効率化を目指す。(→Process Orchestration)
- ISV=Independent software vendor;
- ITSM=IT Service Management, User needsに応じたITサービスの提供と改善;
- IVR=Interactive voice response;
- JEE=Java Enterprise Edition;
- JSON: JavaScriptの簡易的なデータ定義言語; Cf: YAMLはRubyなどで使用する構造化データ
- LCAP=Low-code application platform;
- LDAP=Lightweight Directory Access Protocol;
- MDM=Master data management;
- MQTT=Message Queuing Telemetry transport;
- MXDP=Multi-Experience Development Platform (Web, Mobile, Voice, AR, Chat, Wearable等活用のApp開発Platform); CAGR18%、USD25B(2027)と急成長が見込まれる市場。提供側は単一アプリをIT, Telecom, BFSI, Retail, Travel, Hospitality分野など向けに開発して市場拡大を狙う。
- ODBC=Open Database Connectivity; Platform-agnostic, に依存することなく;
- out-of-the-box: 難しいインストールなしに、箱から出してすぐ利用可能な簡便なソフトウェアなど
- PWA=Progressive Web Apps; RAD=Rapid Application Development;
- RPA=Robotic Process Automation;
- SAML=Security Assertion Markup Language;
- Schema, OS Directoryと似た性質、但し、階層なし, DBで格納場所を別に分類できる仕組み, user名schema→public schemaの優先順位;
- SDLC=Software Development Life Cycle; Single Step Deployment, 顧客や取引先との連携を強化するシステム
- Seed round: 新規ビジネスのアイデア段階での資金調達。Incubator, Seed accelerator, Angel投資家など
- SLA=Service Level Agreement
- SoR= Systems of Record; 記録保管を中心として社内基幹システム; Cf. SoE=Systems of Engagement
- SSO=Single Sign-On;
- TOTP=Time-based One-time Password;
- UI=User Interface;
- UX=User Experience
- WAR=Web application ARchiveで、Java EEアプリのパッケージ形式
Comment
- Information and its update of rapid development tools is also really rapid.
- So-called 'Citizen translator' cannot trace such rapid update.
- 超高速開発ツールに関する情報やそのアップデートもまた実に超高速である。
- いわゆるシチズン翻訳者は、このような超高速アップデートになかなか追いつかない。
Articles about Low-Code Development |
Cat: ICT |
|
Compiled & Translated by Kanzo Kobayashi |
21312u/22816r |
>Top 1-1. Low-code frustration #1:
|
1-1. ローコードへの失望 #1:
|
>Top 1-2. Low-code frustration #2:
|
1-2. ローコードへの失望 #2:
|
>Top 1-3. Low-code frustration #3:
|
1-3. ローコードへの失望 #3:
|
>Top 1-4. Low-code frustration #4:
|
1-4. ローコードへの失望 #4:
|
>Top 1-5. Low-code frustration #5:
|
1-5. ローコードへの失望 #5:
|
>Top 1-6. Low-code frustration #6:
|
1-6. ローコードへの失望 #6:
|
>Top 1-7. Low-code frustration #7:
|
1-7. ローコードへの失望 #7:
|
>Top 1-8. Low-code frustration #8:
|
1-8. ローコードへの失望 #8:
|
>Top 1-9. Low-code frustration #9:
|
1-9. ローコードへの失望 #9:
|
>Top 2. Low Code Development is on the Rise:
|
2 . ローコード開発は伸長している。：
|
>Top 2-1. What are low-code platforms?:
|
2-1. ローコードプラットフォームとは何か:
|
>Top 3. How No-Code Platforms Are Helping SMB's Go Fully Digital: by Artem Ptashnik, RTInsights.com, Oct 26, 2020
|
3. ノーコードプラットフォームがいかに中小企業の全面的なデジタル化に寄与するか: by Artem Ptashnik (2020/10/26)
|
>Top 3-1. How No-Code
|
3-1. 中小企業のためのノーコードツールのメリット::
|
>Top 3-2. Tools for building something (websites, online stores, mobile apps):
|
3-2. Webサイト、オンラインストア、モバイルアプリなどの構築ツール:
|
>Top 3-3. The future is no-code:
|
3-3. 未来はノーコードである。:
|
>Top 4. 10 Best Low-Code Development Platforms in 2021, last updated: Jan. 10, 2021:
|
4. 2021年ローコード開発プラットホームベスト10 (2020/12/28更新)
|
>Top 4-1. Reasons for Using Low-Code Platforms: |
4-1. ローコードプラットフォームを利用する理由:
|
>Top 4-2. Best 10 The Top Low-code Develoment Platforms: (#1-2)
|
4-2. ベスト10 ローコード開発プラットフォーム: (#1〜2)
|
>Top 4-3. Best 10 The Top Low-code Develoment Platforms: (#3-5)
|
4-3. ベスト10 ローコード開発プラットフォーム: (#3〜5)
|
>Top 4-4. Best 10 The Top Low-code Develoment Platforms: (#6-8)
|
4-4. ベスト10 ローコード開発プラットフォーム: (#6〜8)
|
>Top 4-5. Best 10 The Top Low-code Develoment Platforms: (#9-10)
|
4-5. ベスト10 ローコード開発プラットフォーム: (#9〜10)
|
>Top 5. Features of Each Software: (#1)
|
5. 各ソフトウェアの特徴: (#1)
|
>Top 5-2. Features of Each Software: (#2)
|
5-2. 各ソフトウェアの特徴: (#2)
|
>Top 5-3. Features of Each Software: (#3)
|
5-3. 各ソフトウェアの特徴: (#3)
|
>Top 5-4. Features of Each Software: (#4)
|
5-4. 各ソフトウェアの特徴: (#4)
|
>Top 5-5. Features of Each Software: (#5)
|
5-5. 各ソフトウェアの特徴: (#5)
|
>Top 5-6. Features of Each Software: (#6)
|
5-6. 各ソフトウェアの特徴: (#6)
|
>Top 5-7. Features of Each Software: (#7)
|
5-7. 各ソフトウェアの特徴: (#7)
|
>Top 5-8. Features of Each Software (#8):
|
5-8. 各ソフトウェアの特徴: (#8)
|
>Top 5-9. Features of Each Software: (#9)
|
5-9. 各ソフトウェアの特徴: (#9)
|
>Top 5-10. Features of Each Software: (#10)
|
5-10. 各ソフトウェアの特徴: (#10)
|
>Top 5-11. Features of Each Software: (#11)
|
5-11. 各ソフトウェアの特徴: (#11)
|
>Top 5-12. Features of Each Software (#12):
|
5-12. 各ソフトウェアの特徴: (#12)
|
>Top 5-13. Features of Each Software: (#13)
|
5-13. 各ソフトウェアの特徴: (#13)
|
>Top 5-14. Features of Each Software (#14):
|
5-14. 各ソフトウェアの特徴: (#14)
|
>Top 5-15. Features of Each Software:
|
5-15. 各ソフトウェアの特徴
|
>Top 5-16. Additional Platforms to Consider: (#16 - #19)
|
5-16. その他ソフトウェアの特徴: (#16〜#19)
|
>Top 5-17. Conclusion:
|
5-17. 各ソフトウェアの特徴
|
>Top 6. What's the Secret Formula for Innovation?:
|
6. イノベーション成功への公式とは何か?:
|
>Top 7. How Systemized Innovation Enables Digital Transformation: by Alan Glickenhouse, RTInsights.com, Mar 13, 2019
|
7. いかにシステム化されたイノベーションがDXを可能にするか: by Alan Glickenhouse, TRInsights.com, 2019/3/13:
|
>Top 8. Clearing up misconceptjons about APIs and Microservices, by Alan Glickenhouse, IBM Middleware User Community, May 30, 2018:
|
8. APIsとMicroservicesに関する誤解の解消、by Alan Glickenhouse, IBM Middleware User Community, 2018/5/30:
|
>Top 9. What is an API? and What is API Economy? : by Alan Glickenhouse, IBM Middleware User Community, Jan 04, 2018:
|
9. APIとは何か、API Economyとは何か: by Alan Glickenhouse, IBM Middleware User Community, 2018/1/4:
|
>Top 10. API Monetization - What does it really mean?:
|
10. API Monetization - その真に意味するもの:
|
>Top 12: Acronym & Jargon: (用語集)
|
Comment |
|
|