ITアーキテクチャが重要である理由をお話ししましょう。理由をお話ししましょう

描画が大好きです!!

(Miguel Angel Coll)(2020年7月2日)

私は過去5年間、ITアーキテクチャ機能に取り組むキャリアに投資しました。その間ずっと、私は自分自身にも建築機能の単なる存在を正当化する必要がありました。時には、私たちが実際に仕事をしている人々(開発者、シスオペ)に囲まれた侵入者のように感じることもあります。

5年経った今でも、アーキテクチャが重要であると確信しています。

コストパフォーマンスに優れた

ITアーキテクチャのミッションを1つだけ選択する必要がある場合は、これを選択します。 IT部門とプラットフォームは、通常、成長を続けています。会社が成長しているためのものもあれば、会社がデジタル変革の真っ只中にあるためのものもあります。いずれにせよ、結果は同じです。年々、システム、チーム、複雑さが増しています。

ITプラットフォームを次のように過度に単純化するのが好きです。

主なアーキテクチャ機能は、との関係を維持することです。 ITプラットフォームのコストとそれが良い形で提供する価値。

しばらく前、私は旅行会社で、APIを介したオンライン製品配布に基づくビジネスモデルで働いていました。これらのAPIは、OracleExadataに基づく巨大なモノリスシステムと強力に結合されていました。つまり、APIトラフィックが増加するたびに(そしてトラフィックがコンバージョン率を超えて増加するたびに)、データベースを垂直方向にスケーリングする必要があります。

アーキテクチャがITプラットフォームの効率を向上させる

当時のアーキテクチャの提案は、APIサービスを分離して、上に新しいマイクロサービスレイヤーを作成することでした。クラウドは、予約と運用のためだけにデータベースインフラストラクチャを維持しながら、すべてのトラフィックを低コストで処理します(残念ながら、指数関数的に成長することはありません)。その結果、次の年にはDBに必要な新しいインフラストラクチャがなくなり、トラフィックとITコストの関係が改善されました。

同じ言語を使用する

心配しないでください。プログラミング言語(Java、Pythonなど)について話していません。アーキテクトとして、私は(混沌ではなく)ある程度の制御を備えた多様性に対してオープンです。ここでは、フレデリックPの人月の神話とその他のソフトウェアエンジニアリングに関するエッセイで初めて読んだ ConceptualIntegrity という用語を参照しています。 .Brooks Jr.

本の中で、Fred Brooksは、ITチームがどのように成長し、その成長が生産性にどのように影響するかを説明しています。フレッドにとって、ITチームを拡大しようとするときに取り組むべき最大の問題の1つは、チーム間のコミュニケーションです。タスクを並列化するには、チームができるだけ独立している必要があります。ただし、すべてのチームが相互接続されたプラットフォームで作業するとすぐに、チーム間のコミュニケーションが必要になります。共通の言語を持つことが成功の鍵となるシナリオにあります。

システム、テクノロジーコンポーネント、インターフェース、またはビルディングブロックとは何かについて話し合った以前のチームメイトとの終わりのない会話を今でも覚えています。大規模なIT部門で働いている場合は、チームによって名前が異なることでイライラすることをおそらくご存知でしょう。異なるものに同じ名前を使用すると、最悪の場合もあります。

最後の例の一般的な例は、1つの名前だけでモノリスアプリケーションに名前を付けることです。それが理にかなっているとしても(それはモノリスなので)、そのモノリスを壊したいときは、より詳細な情報が必要になります。データベース、フロントエンド、データモデルなどに異なる名前を導入すると、プロセスに役立ちます。

小規模なIT部門や大規模な部門であっても、開始するのに適した時期です。命名規則、サービス/システム/ソリューションカタログなどがあります。将来どのくらいの規模になるかはわかりません。

概念の整合性について

設計の会話を強制する

私の考えでは、問題のすべての解決策は常に、実装前の状況の分析とソリューションの設計。開発チームの現実は、毎週、解決すべき新しい問題がテーブルにあるということです。通常のルーチンとして数か月のビジネスの後、チームは自動操縦で実行を開始し、中長期的な影響についてあまり考えずに問題の解決策を見つけるだけです。

アーキテクチャ機能を開発チームに統合することは常に役立ちます私たちが直面している問題の最善の解決策を見つけるために、デザインの会話を増やすことについて。

また、私は、デザインが最初に行われるべきものと見なされる古いファッション開発プロセスに挑戦したいと思います。事業。記事 建築家エレベーター—上層階への訪問 Gregor Hohpe は、アーキテクチャの役割についての私の理解を完全に説明しています。

「…したがって、すべての重要な決定を1人に任せる代わりに、プロジェクトのリスクを不可逆的な決定の数を最小限に抑える。」

すべての開発プロセスにアーキテクチャが存在する必要があります。実際、アジャイルに取り組んでいる場合は、すべての反復で意思決定を行うことになります。

戦略の議論

IT担当者として、私は非常に具体的な会社の取締役会に参加したいと思っています。と詳細な技術的な議論。中規模および大規模企業の現実は、取締役会のメンバーが詳細について深く掘り下げる余裕がないということです。しかし、会社の取締役会はITの状況を理解せずに戦略について決定を下す必要がありますか?

現在の世界では、ITが戦略の中心にないと言える企業はほんのわずかです。では、戦略をITに、またはその逆に変換する責任は誰にあるのでしょうか。 —あなたはすでに答えを知っています。

TUI Destination Experiencesアーキテクチャチームでの最大の貢献の1つは、ターゲットアーキテクチャモデルを描くことでした。 TAMにより、IT以外の人々は、当社の主要なソリューションとシステム、およびそれらが当社のバリューストリームにどのように関連しているかを理解できます。 TAMを配布した後、戦略に関する会話のほとんどは、アーキテクチャがどのように見えるか、新しい状況にどのように適応するかを検討することから始まりました。

ただし、ターゲットアーキテクチャモデルは静的なものではないことに注意してください。 「現状」および「将来」のアーキテクチャの図。そのような演習を行おうとすると、特定のプロジェクトにぴったりの一時的なものになってしまいます。私の意見では、アーキテクチャの主要コンポーネントを描画し、保持したいものを選択し(ビジネスの中核であるため)、変更または進化させる必要があるものを指摘することに焦点を当てたほうがよいと思います。

TAMプレゼンテーションの最初のスライド

Visaの創設者であるDeeHockが言ったことを常に覚えておいてください:

シンプルで明確な目的と原則は、複雑でインテリジェントな行動を引き起こします。複雑な規則や規制は、単純な愚かな行動を引き起こします。

無限のかなたへ

アジャイルへの執着は、ITチームを短期的な意思決定者に変えることがあります。 。すでに説明したように、今日行っている決定が将来を見据えたものであることを確認する必要があります。長期的な戦略を明確に把握することを意味する場合もあります。場合によっては、将来に合わないソリューションに縛られないように注意することを意味します。 ほとんどの場合、デフォルトレベルの品質を保証し、来たものすべてに適応できることを意味します。

すでにコメントしたように、アーキテクチャは戦略レベルでも機能する必要があります。つまり、ITプラットフォームに影響を与える可能性のある将来の可能性についての新鮮な情報がおそらく得られるということです。時には、それらの戦略的変更は機密でさえあります。後悔の動きを避けようとするいくつかの決定に影響を与えることができることは、知識のない人々が背後にある本当の理由を理解することは決してないため、時には難しい作業です。

ある時点で、私たちはB2Cプラットフォームのアーキテクチャの改善に関する議論。アーキテクチャを大幅に改善することは本当に理にかなっています。しかし、私たちの中には、B2Cプラットフォームに代わる会社を買収するために話し合っていることを知っている人もいます。

私を信じてください。建築家になるのは必ずしも簡単ではありませんが、常に何を考えなければなりません。会社に最適です。

そして…

…また、私たちは絵を描くのが大好きで、オフィスをもっとクールにします。

アーキテクチャ図を使用して議論する開発チーム

この控えめな投稿を希望します将来、このような美しい仕事を理解するために貢献してください。

Tui DestinationExperiencesのテクノロジードメイン責任者であるMigueColl。