「複雑」とは、テクノロジー、機能の異質性、他のアプリケーションとの接続性、重要度、年齢、サイズなど、かなり印象的な属性を持つ、数百のビジネスアプリケーションです。 ここにダイナミクスを追加します。数十の社内および社外のチームがたゆみなく変化します。 言い換えれば、最も熱心な、または安定した専門用語では、「血なまぐさい」企業です。
明らかに、この熱狂的な大釜では、それぞれの新しい変化のイニシアチブは検索から始まりました：どこで何をすべきか、変化の十分性と必要性を判断する方法。 つまり、分析が実行されました。 また、ボイラーは大きく、変化の度合いが大きいため、分析と分析は高品質でなければならず、数か月間続きました。 しかし、徹底的には100％の品質を保証しませんでした。なぜなら、あなたのイニシアチブと同じ牧草地では、他の人が思いがけない変更を加える可能性があるからです。
誰かが、これは「血なまぐさい」企業の通常の状況だと言うでしょう。 アジャイルチームが製品の唯一の所有者を扱っているかどうか。 すべてが考慮され、チームはすべてを知っています。 私は議論しません。 多くの点でこれは真実です。 しかし、引き裂かれたパッチワーク環境で独立したチームを構築することはできません。 しかし、本当に大きなタスクを1つのチームで解決することはできません。 そして、どの方法論でも合理的なレベルの秩序が必要です。
単一のアーキテクチャーリポジトリ
私たちが始めたのは、物を整理することでした。 これにより、単一のアーキテクチャリポジトリが作成されました。 彼のメタモデルから始めましょう。 私の意見では、そのような変化は常にメタモデルの開発から始まるべきです。 これは、利害関係者に、そして最も重要なことに、私たち自身に、新しいリポジトリが提供できるものを説明するための最良の方法です。 メタモデルは、リポジトリが実装されるシステムの機能に目標がどのように当てはまるかを示します。 開発する場合、最も簡単な方法は、すでに社内にあるドキュメントを調べることです。 経験から学ぶ。 さまざまなベンダーのバニラモデルを見てください。 本当に深刻な場合は、GOST、たとえばGOST 57100（ISO 42010）を読んでください。
開始するには、メタモデルに最も必要なものだけを含めてください。単純なものから始める方が良いからです。 そして、そのようなモデルが十分でないことが判明した場合、それを開発することは難しくありません。 さらに、開発は意識的になります。 つまり、最も正しいアプローチは反復的です。 アーキテクチャの小さな部分から始めます。 モデルがどのように処理するかを確認してください。 目標に十分な要素、接続、属性があり、その開発について決定を下します。
私たちは、純粋に実用的なメタモデルにアプローチしました。 3つの目標が有望であると特定されました。
- 現在の建築の風景について説明してください。
- 現在の状況に基づいて、変更のためのソリューションアーキテクチャを作成できます。
- リポジトリを最新の状態に保ちます。
モデルはTogafのアイデアに基づいていました。 いくつかのレイヤーがあり、リポジトリの2つの部分、CurrentとSolutionを表します。 現在の「現在」を簡略化した形で図に示しています。
ソリューションは基本的に「現在の」構造を繰り返しますが、いくつかの機能があります。
モデルはまだ非常に単純ですが、最初のオプションははるかに単純でした。 これは単なるアプリケーション層でした。 次に、リポジトリ、コンポーネント、ビジネスオブジェクト、およびビジネスレイヤーで補充されました。
時々、モデルの簡潔さの結果を感じますが、私たちにとっては、それを複雑にするのではなく、リポジトリアーキテクチャとリポジトリ内の情報の関連性によってカバーされる領域にはるかに重要です。 したがって、リポジトリに関連情報を維持するのに十分なエネルギーがあり、同時に詳細レベルがアーキテクチャを分析し、イニシアチブのソリューションを作成するのに有用かつ十分であるときに、その中間点を見つけたようです。
私たちのリポジトリはSparx Enterprise Architectに基づいています：ソリューションをカスタマイズするためにこのシステムが提供するほとんどすべての可能性が使用されました-それは独自のメタモデル（MDGテクノロジー）を使用し、JavaおよびJavascriptの数千行のコードでサポートされています。 もちろん、カスタマイズは独立した開発とサポートの必要性につながりますが、私たちはこの準備ができていました。
現在のアーキテクチャ
リポジトリの現在の状態についてもう少し詳しく説明します。
ビジネスレイヤーレベルでの主な要素は、ビジネスサービスと使用シナリオです。
サービス：
そして使用シナリオ：
この場合、使用シナリオでは、アプリケーションの特定の条件におけるビジネスサービスの詳細を示します。 それでも、シナリオはビジネス機能のかなり大規模な表現です。
使用シナリオはアプリケーションによって自動化されます-これは、アプリケーションが情報フローによって相互接続されるアプリケーションアーキテクチャレベルです。
ストリームには、データアーキテクチャレイヤーからのビジネスオブジェクトが含まれます。
アプリケーションアーキテクチャの基盤はコンポーネントアーキテクチャであり、各アプリケーションはその構造をコンポーネントの形で表現し、フローはインターフェイスを介したコンポーネントの相互作用の形で詳細に記述されます。
ここで、前述の要素とそれらの関係をもう一度見てください。 すべてが非常に単純ですが、大規模な銀行のアーキテクチャを適切に記述することができます。 数年間の作業の後、ほぼ1万のアーキテクチャ要素がリポジトリに蓄積され、その間に数万のリンクが形成されました。 そして、これはまさに現在のアーキテクチャです。
ソリューションのアーキテクチャ
上記の目標の2番目の段落に目を向けます。 アジャイルを含むさまざまな方法論に従って実装された、さまざまな規模のイニシアチブのためのソリューションアーキテクチャを作成する必要があります。
ソリューションは、アーキテクチャの各層について説明されています。 リポジトリのソリューション部分のメタモデルは、基本的に現在の構造を繰り返しますが、違いがあります。 たとえば、属性のセットは部分的にしか交差しません。 さらに、ソリューションパーツの要素と関係には、ソリューションの説明に必要な一連の属性があります。
ソリューションの4つのレイヤーすべてを見ていきましょう。
ビジネスアーキテクチャには2種類の要素が含まれます。 これらは、プロジェクトに実装されている大規模なユースケースと、アジャイルイニシアチブの場合の「ウォーターフォール」プロジェクトまたはユーザーストーリーのより詳細な要件です。 さらに、ユースケースでは、現在の部分に独自のミラーが必要です。 同時に、要件とユーザーストーリーはソリューションパーツのみの要素であり、現在のパーツには表示されません。 もう1つの重要な詳細：Sparxリポジトリは、それらのマスターシステムではありません。 他のシステムからエクスポートされます。
要件とユーザーストーリーは、それらを担当するアプリケーションにマップされます。
残りのソリューションアーキテクチャレイヤーには、現在のアーキテクチャに類似した図があります。
ソリューションアーキテクチャの要素と接続の配色は、アーキテクチャの変更の外観を伝えます。 変更の説明は、要素とリンクの対応する属性、および要素に添付されたメモの両方に入力できます。
このデータに基づいて、アーキテクチャドキュメントの対応する部分が生成されます。
しかし、実践が示すように、最も一般的なのは図です。 これらは、エンタープライズアーキテクト、開発チーム、ベンダー、および建築委員会との議論で使用されます。
最も注目すべき点は、リポジトリの「一意性」により、図で使用されているすべての要素と関係が文書化され、ディスカッションのすべての参加者が一様に理解していることです。 したがって、最初はすべての参加者が同じ波長を使用します。
 |  |
|---|---|
| 大規模なイニシアチブを分析する場合、ソリューションアーキテクトは情報の検索に時間を浪費しません | ソフトウェアアーキテクトは、ソリューションアーキテクチャを勉強するとき、彼にとって馴染みのある要素を見ます。 彼はこのアーキテクチャが何であるかを理解しています。 |
別の素晴らしい瞬間。 ソリューションアーキテクチャの説明は、現在の状況を実現するのに十分です。 したがって、実稼働環境でソリューションをリリースすると、スクリプトを使用したアーキテクチャの変更がソリューションパーツから現在のパーツに転送されます。
この相互接続のおかげで、ランドスケープは、ランドスケープを変更するための継続的なイニシアチブにもかかわらず、引き続き重要です。
リポジトリのサポート
多数のユーザーが作業する、このような非常に多くの要素とリンクを持つリポジトリーは、適切な状態に維持する必要があります。 たとえば、すべての必須属性を入力する必要があります。 要素間の接続は特定の種類でなければなりません。 さらに、アプリケーションとコンポーネントアーキテクチャの状態は、同じアプリケーションを表しますが、詳細度が異なるため、互いに対応する必要があります。
もちろん、ユーザートレーニングは重要な役割を果たします。 しかし、これは非常に小さいです。 人々は間違いを犯しがちです。 JavaとJavaScriptコードでこの問題を軽減しました。 毎晩、スケジュールに従って、私たちの生活を大いに促進するスクリプトが実行されます。
- メタモデルに準拠しているかどうか、リポジトリの内容を確認してください。 スクリプトは、エラー自体を修正するか、人間の介入の必要性を示します。
- 現在のコンポーネントアーキテクチャに基づいて、現在のアプリケーションアーキテクチャのコンテンツを生成します。
- リポジトリの内容を視覚化するために、いくつかのタイプの図が生成されます。
- 準備されたイニシアチブのソリューションアーキテクチャドキュメントを生成します。
- リポジトリのコンテンツは、HTMLポータルへの一般的な銀行アクセスにアップロードされます。
- シンプルなメタモデルのもう1つの利点は、そのシンプルさにより、自動化スクリプトもシンプルになっていることです。
結論
今日とその「先史時代」の2つの状態を比較すると、建築家の要件が増加していることが明確にわかります。 何らかの理由でアーキテクチャの分析が必要な人にとっても、参入のしきい値は大きくなりました。
リポジトリのメンテナンスを担当する人々がこれに多くの時間を費やし、私たちの場合、コードを開発できることが非常に重要です。
リポジトリのメタモデルに戻ると、単純なモデルのフレームワークでは、多くの利害関係者の意見をまとめることは非常に困難であり、長期にわたってそれを維持することはさらに困難です。 そして、メタモデルの変更は何らかの形で自動化スクリプトに反映される必要があります。
一方、アーキテクチャ分析とソリューション設計は、よりシンプルになり、大幅に短くなりました。 ソリューションアーキテクチャの品質は一桁向上しました。 ソリューションはより詳細になり、常に一貫性が保たれています。 アーキテクトの作業により、ドキュメントの準備に関連する日常的な操作が最小限に抑えられ、ドキュメントを最新の状態に保つ必要があります。 建築家は本当に創造的です。
結論として、リポジトリを実装するために使用したツール、Sparx Enterprise Architectについて少し説明します。 私の観点から、それは傑出した価格/品質比を持っています。 もちろん、これは主に低価格によるものですが、必要な機能はほぼすべて揃っています。
不足しているのは、アーキテクチャリポジトリ内のさまざまなインタラクティブデータビューです。 実際、それらを使用しない定性分析は非常に困難です。 Sparxデータベースへの単純なSQLクエリから直接始めました。 しかし、彼らは独立した開発によってこの問題を解決しました。 Sparx自体に加えて、カスタムWebアプリケーションを使用してリポジトリを確認します。最も一般的なビューは、選択した値に応じてフィルター、ソート、トレースする機能を備えた表形式で表示されます。
