自動再構築BPMS

BPMSやコード自動生成ツールを使ったシステム開発は、まだ本格的に流行っているようには見えない。だがこれらは大いに将来性があると考えている。今流行っていないのは、それがまだシステムとして未熟だからだろうと思う。

どこが未熟なのかと言うと、アウトプットがスケールアウトモデルになっていないところだ。単純な話、出力がAmazon Lambdaになれば良いのではないか。それが極端だというなら、OpenStackに吐くようにしてはどうだろう。

BPMSやコード自動生成ツールにおける「ソース」は、ほぼ仕様そのものだ。これに合わせて実装の仕様たる「非機能要件」があるが、これも別にソースとして定義してやる。実装は全て後者に集約するようにすれば、仕様が分からずに移植できない、ベンダを変えられない、などということはないはずだ。

もちろん、大規模システムにおいてはそう簡単にはいかないだろう。システムの融通も利かないかもしれない。例えば、オンプレミスのリソースを食い尽くしてしまって他のシステムに迷惑を掛けるとか、必要以上に高速処理をする一方でアイドル時間の多い、無駄飯喰らいを構成してしまうかもしれない。

ここは「非機能要件」を使用した最適化ということになるのだが、将来的にここはAIが活躍する場となる可能性がある。

ある仕様を満足するために必要なシステム構成には、非常に多数の選択肢がある。そのどれを選ぶかは、一応目安はあるものの、SEの経験と勘が効くエリアだ。そこで、コード自動生成によるスクラップ＆ビルドが可能な環境とAIが組み合わさることで、思わぬ最適化ができる可能性がある、というわけだ。

これは副次効果もあって、例えばパブリッククラウドだったら、システムトラフィックの変化や新しい料金体系が出来たなどの細かいタイミングで自動的に見直すことができる。オンプレミスであっても自動構築が可能なので、ハードウェアリプレイスや故障対応などでも最適化ができる。

もちろんDR(災害時の対応)にもこれは発揮される。どうしても足りないときにはパブリッククラウドを借りるなど、一時的にポリシーを変更しても再構築が自動にできるから、システムを止めることなく運用できる。

そのためなら、予算ギリギリにしてオンプレミスでカリカリチューンするよりは、トータルでは上手く廻るのではないか、と思う。