Gartner社がウェビナーでエンタープライズアーキテクチャとアプリケーションアーキテクチャの最良の設計方法と最悪の設計方法を解説している。
同社のバイスプレジデントのBetsy Burton氏とバイスプレジデント兼フェローのAndy Kyte氏がBest and Worst Practices in Enterprise & Application Architectureと題したウェビナーを開催した。Betsy Burton氏は始めにエンタープライズアーキテクチャのための10のベストプラクティスを紹介している。
- 企業の文脈に合ったEAの計画を採用する – EAをビジネスの文脈全体の中に置く。既存のビジネスの戦略を意識しないとEAは成功しない。
- コミュニケーションの計画を開発する(そして実行する) – ビジネスとコミュニケーションし、現在のEA開発の価値の概略を示す。
- 実利的であること
- 各イテレーションをプロジェクトのように扱う – EAはプロジェクトではないが、各プロジェクトはプロジェクトのように扱える。
- ビジネス戦略から始め、ビジネススポンサーシップを獲得する。
- 現在の状態よりも前に未来の状態に取り組む – 現在の状態から始めると“ぼんやり”とした状態になってしまう可能性がある。現在の状態を研究する前に、どこへ行きたいか、何をしたいのかをはっきりさせたほうがいい。
- ガバナンスを忘れない – エンタープライズアーキテクトは“組織全体の中で人々が働くことを促し、支援し、協力する”
- 評価方法を準備する(性能の管理と共に) – EA計画の成果を測定する。
- EA計画の成熟と浸透を追跡する – 人々は組織のEAの成熟度について、まったく異なる考え方を持っている。
- 人々の専門技術力と同様に他の能力にも同程度の注意を払う – 専門技術だけでは不十分。コミュニケーション能力なども重要だ。
Betsy Burton氏は13のワーストプラクティスを挙げている。中にはべストプラクティスを反対にしたものもある。
- ビジネス戦略策定と予算確保に関わりを持たない
- "ITアーキテクチャ"と"エンタープライズアーキテクチャ"の混同 – EAはビジネス全体を進化させる取り組みであり、ITはEAの一部分である情報技術を担う。
- ガバナンスの欠如
- 過剰な標準化
- EAの成果ではなく手法にこだわる – ビジネスの成果がEA全体を促進する
- EAのフレームワークに厳密に従う – エンタープライズアーキテクトの90%は複数のフレームワークを使うが、料理の本に従うようにフレームワークに従っているわけではない。そしてそれは正しいやり方だ。
- "象牙の塔"的手法
- コミュニケーションとフィードバックの欠如
- IT系のリソースだけを使ってEAチームを編成する – チームにビジネス側の人間を入れるとよい。
- 性能測定の欠如
- ビジネスのニーズを理解する前にツールを選ぶ – ツールはEAを支援するものであり、EAを促進するものではない。Betsy Burton氏はまずEAのイテレーションを実施してから、どのようなツールが良いかを判断するのを推奨している。
- 最初に現在の状態に注目する。
- "成し遂げた" – EAに終わりはない。ビジネスのニーズに合わせて継続的に進化するプロセスを確立する必要がある。
Andy Kyte氏はEAの文脈でのアプリケーションの設計のベストプラクティスを説明し、多くのエンタープライズアーキテクトが以前はアプリケーションアーキテクトを務めており、ソフトウエアを使ったソリューションに傾きがちであると指摘している。氏は、エンタープライズアーキテクトは一歩引いて、ソリューションのエコシステム全体を見渡せる視点を持ち、変化し続けるビジネスの世界でそのソリューションがどのように効果を持つのか評価することを勧めている。
ライフサイクルを考えなければなりません。運用、メンテナンスやサポート、強化や拡張、ビジネスインテリジェンスなど、アプリケーションのエコシステムを通じて必要なサービスの融合について考える必要があります。そうすることで、…目的を達成するためにシステムに盛り込みたい特徴が何なのか…問うことができるのです。
敏捷性や応答性、信頼性の観点から必要な特徴をどのように手に入れるか。これらの特徴のメンテナンス性をエコシステム全体のライフサイクルの中でどのよう確保するか。このようなことを問うことができるのです。
Andy Kyte氏はプロジェクトの成功を、開始時にどのくらい上手く稼働したかではなく、“システムのライフサイクル全体の中で関係者の要求にどのくらい答えているか”によって判断するべきだ、と主張している。
Andy Kyte氏はソフトウエアの品質を向上させるためのアプリケーションアーキテクトの役割を解説している。氏はまず、6つの観点からソフトウエアの品質を定義するISO 25010について話をしている。6つの観点とは、信頼性、利便性、効率性、メンテナンス性、移植性だ。氏は、ソフトウエアの機能に着目しすぎるアーキテクトがいることに注意を促し、これらの要件は、競争力やビジネスの要請によって変化すると指摘している。“インクが濡れているときには正しいかもしれませんが、乾いてしまったら手遅れになることもあります。” システムのライフサイクルの中で変化は頻繁に起こるので、アーキテクトは上述の機能以外のソフトウエアの品質の観点について考慮する必要がある。特に重要なのはメンテナンス性だ。メンテナンスがしやすければ変化に対処しやすいからだ。
Andy Kyte氏はメンテナンス性の下位区分を説明している。それは、分析しやすさ、変更しやすさ、安定性、テストしやすさだ。例えば、分析しやすさについて言えば、“860,000行のJavaコードを読めばどんなシステムか分かるというのなら、そのシステムは分析しやすいとは言えません。”Andy Kyte氏はコードとプロセスのワークフローを文書化して、システムの分析しやすさを向上させることを考える必要があると主張している。
成功するためには、アーキテクトはアプリケーションの年次のコストや寿命、機能、敏捷性、移植性、利便性、安全性、開発コストなどを考慮し評価しなければならない、というのが氏の結論だ。
氏が勧めるのは、細部に注意を払い、アプリケーション開発のすべてのフェーズに関わり、ガバナンスのプロセスにも参画することだ。
参考資料: スライド (PDF).