システム障害が発生してしまうと、どの会社でも上層部・経営陣に対して説明・報告をするだろう。そこで大きな問題が起こってしまうケースが多い。
技術的な領域や製品・プロダクトが原因で障害が発生した場合、えてしてシステムに疎い経営陣の場合、その製品に対して悪いイメージを持ち続けてしまう事がある。
最近ではWindowsServerのMSCSの不安定さからフェイルオーバーに時間がかかったり、そもそもフェイルオーバーせずストップしてしまう、という事象が多い。なぜかIA64のDBサーバで。その際、正しく・しかも分かりやすく報告をしないと「またSQL Serverか・・・そんなDBやめてしまえ！」という結果になりかねない。MSCSの場合はSQL Serverではなく、OSのサービスなのである。
まぁ他にも似たようなケースは多々あるだろう。
そこで大きな問題となるのが、会社としてのアーキテクチャーの軸足がおかしな理由で狂ってしまう事である。
オープン化の波が到来して早10年近くになるが、現状ではシステムを開発する際のアーキテクチャーの選定は多種多様な技術、製品、思想などから組み合わせなくてはならず、確固たる品質を確保できるアーキテクチャーの軸を持つべきだと考えている。
うちならStrus＋Seasor＋S2Dao、うちはMSアーキテクチャーで固める、など。
1つのアーキテクチャーだけに偏るのはよろしくないが、1つベースラインを持つべきだとは思う。
アホな報告を経営陣にしてしまったがために、おかしな方向に行ってしまう事だけは避けたいところだ。アホっぽい話だが、実際にあり得る話である。。。