前回の続きですが、なんと言うか、Elastic Stackについては、以下のWikiに纏めましたので、Blog上では、それ自体に言及する気は無いのですが、
Elastic Stack、業務的には、ワリと汎用的なんでしょうけど、スタックは、Elastic Stack言っているだけあって、組み合わせ（スタック＆コラボレーション）はあまり自由度がない気がしました。となると、当該ソリューションに特化した構築屋がワリと遣り易いんじゃないかと思ったりシます。
...で、DXはPO（Product Owner）が中心となった内製になって行く事を考えると、従来の受託感覚で、個々のプロダクトを理解することがあまり、エンジニアリング的にならないンじゃないかなぁ。...と思ったりもするんですが、そうならないように、大手企業は、協創、PoC後、サービス化みたいなイメージで、ユースケースの研究に全振りしている気がしますね。
...となると、繋ぎ目部会のポジショニング的には、
以前にも書きましたが、やっぱり、ビッグデータやAI（BI）の基盤は、ワリと、要素技術屋さんが陣取り易いトコロだと思うので、敢えて、我々がソコをやる必要はないだろうという話で、データ・パイプライン中のIoTのDevice / Edge部分や、ETL / Streaming部分に対するリサーチとサポート提供の追加を目標に活動をしていこうと考えています。
手始めに、IoT Device向けのOAuth2フローである「OAuth 2.0 Device Authorization Grant」を実装し、ETL / Streamingツール類 の NiFi, Kafka, Stormなどの組み合わせ事例の評価をAzure HDInsight上で実施予定です（昨今、PaaSやSaaSによりクラスタが提供されているので、Dockerを使用して、個々のプロダクトを評価するような機会も少なそうですね）。
みたいな感じの活動計画になるんじゃないか？と思いました。
要するにユースケースに詳しくなって、既存のビッグデータやAI（BI）の基盤ソリューションを中心に組み立てができるようになっていくと良いんじゃないか？と思いました（世間一般で言う、データ エンジニアの役割に近い）。
この様に大手では、ユースケース屋、PgM、PdM、PjM、基盤屋、繋ぎ目屋等々、専業分化が進んでいくものと思われ、弊部会は、ソリューション化できなさそうな手薄な守備位置を（、いつもの如く）、守ることになりそうだな。などと思ったりシました。これが、今後のプログラム構成検討のベースになると思います。
Open COBOL Solution WG
Elastic Stackをスタック＆コラボの事例として研究する（３）
