architecture - ソフトウェアをビジネスプロセスに合わせる方法は？

Question

私の経験では、ビジネスプロセスとうまく連携しているソフトウェアは、ビジネスプロセスが変更されたときに変更しやすくなります。このアプローチに最適なアーキテクチャのタイプは何ですか？

Answer 1

良い質問です...しかし、まず... SOA? これは素晴らしいバズワードですが、誤解されることがよくあります。その主な原因は、「実際の」定義が 1 つもないことです。なんてこった！Martin Fowler でさえ、今ではそれを「ServiceOrientedAmbiguity」と呼んでおり、人々にそれを一切持ち出さないように勧めています。

「 1」「ベスト」な答えは本当にありません。企業が IT に課す要求には、次のようなものがあります。そして通常はそうです。かなり多様。これらの要求は、多くの場合、顧客、パートナー、市場動向、法律、規制当局などの外部要因の影響を受けます。多くの場合、これらの要因はアーキテクチャを決定するか、少なくとも「より良い」と思われるものを完全に達成する能力を妥協または制限します。 " 建築。それもばかげているように聞こえるかもしれませんが、それは私の意図ではありません。「最高の」アーキテクチャなどがあるという考えは、多くの人がその追求に膨大な量のエネルギー (およびお金) を浪費し続けるように導きます。意図的ではないかもしれませんが、これらの視点は、多くの場合、単一のベンダー/コミュニティの代理人になった人々によって支えられています。

とはいえ、ソフトウェア エンジニアリングの観点から見ると、ビジネスの要求を満たすための最も信頼できる手段は、今でも古い考え方のままです。例えば、

• 懸念事項を分離する
• アーキテクチャを階層化する
• 柔軟性を考慮した設計
• レイヤーを個別にテストしてから、それらをまとめてテストする
• 継続的インテグレーション プラクティスを採用して、リグレッションをより早く可視化する
• 要件と仕様を主要な推進要因にする
• ツールに投資し、開発者に投資する
• 等...

アーキテクチャ パターン、テクノロジ、または言語について言及されていないことに注意してください。これは、これらが実際には原動力ではないためです。ただし、それらはイネーブラーである可能性があり、さまざまな要因によって変化します。もう一点触れさせてください。「ビジネス プロセス」とソフトウェア エンジニアリング プロセスでは、懸念事項や視点などが大きく異なります。いずれかのグループを他のグループと同じように機能させることは、完全な失敗につながるだけです。日付や機能的な成果物などのコミットメントを共有すべきではないというわけではありません。これらのグループは、効果的に仕事を行うために異なる必要がありますが、共有されたビジョンを必要とすることを伝える方法を見つける必要があります。これは、いくつもの設計およびライフサイクル管理プロセスが役立つ場所です。(例: DDD、MSF、SCRUM、CMMI など)。

私はこれが建設的であることを意味しました...お役に立てば幸いです。

Answer 2

ばかげた答え: エンタープライズ アーキテクチャです。

あなたが本当に求めている答えは何ですか？私の経験では、特にビジネスが進化したい方向性に関しては、それぞれのビジネスに独自のニーズがあります。ギャグルの残り。