仮想パネル：ソフトウェアアーキテクチャの文書化について
Len Bass氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、Software Architecture in Practiceと、もうすぐ第2版の出る "Documenting Software Architectures: Views and Beyond"の共著者。 Grady Booch氏, IBMフェロー、 Webサイト"Handbook of Software Architecture"の著者 Paulo Merson氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、"Documenting Software Architectures: Views and Beyond"の共著者 Eoin Woods氏, Barclays Global Inve
アーキテクチャドキュメントに必要なこと [arch]
最近本腰を入れて大掛かりなアーキテクチャ設計をしようとしているが，ドキュメントを書く際にいつも帰ってくるのがこのエントリー． Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal: What should be in an Architecture Document? とても素晴らしい内容なので，以下に意訳しておきます．ぜひ原文も合わせて読んでみて下さい． - ドメインモデル (もしあれば)，使用されているパターン，ガイドラインなどに特化したドキュメントを合わせて紹介すること．アーキテクチャドキュメントは，それらのガイドラインと整合性を保つこと． - 1つのドキュメントは50ページを超えないこと．肥大化したドキュメントは誰にも読まれない (少なくともその全ての内容は)． - 当たり
ITSSv2で明らかになった「ITアーキテクト」（前編）
2006年7月，IPA（情報処理推進機構）のITスキル標準センターは，ITアーキテクトの活動プロセスやスキル体系を報告書にまとめて公開した。内容は，約2年間にわたって活動してきたプロフェッショナル・コミュニティ（ITアーキテクト）注1がまとめた成果物であり，大きく「ITアーキテクトの活動プロセス」と，ITスキル標準（ITSS）v2に盛り込まれた「ITアーキテクトの専門分野とスキル体系」に分かれる。ここからは，これらを基に説明する。 実は，ITアーキテクトが開発プロジェクトに参加しない例はよくある。つまり，ITアーキテクトが存在しなくても，システムは出来上がる。では，IT アーキテクトの存在意義は何か。今回の報告書ではまずその点を明らかにした。具体的には「要求者と設計者の橋渡し役」と位置づけている（図1）。 図1●ITアーキテクトの仕事の流れ（活動プロセス） ITアーキテクトは，要求者からの
なるほど！ ビジネスユースケース ― ＠IT情報マネジメント
UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース：The Rational Edge（1/2 ページ） The Rational Edgeより：IBM Rational Software Architectをはじめとする各種モデリングツールではユースケースのモデリングにどのUML図を使うのかなど、ビジネスユースケースとシステムユースケースの相違点と類似点について学ぶ。 ビジネスプロセスアナリストは、まずしっかりしたビジネスモデルを開発してから、冗長作業の排除や、繰り返しが多く平凡な、もしくはエラーの影響を受けやすい作業の自動化など、各種ビジネス改善オプションを調査する。「IBM Rational Unified Process」（RUP）と「Unisys 3D Visual Enterprise」（3D-VE）は、Unified Modeling Language
変化に強いシステムのためのアーキテクチャ － ＠IT情報マネジメント
アプリケーション保守は開発より大変といわれることがある。こういう場合の保守は、バグ修正などではなく、扱う商品や制度の変更などに対応するための修正作業であることが多い。世の中の変化は予知できないことが多いが、柔軟なアーキテクチャによりシステムを変化に対応しやすくすることはできる。Dependency Injection（DI）をはじめとする、さまざまな手法を取り入れて変化に強いシステム構築を目指そう。 企業の情報システムを取り巻く環境変化として、次のようなものが考えられる。 取扱商品の増加、販売チャネルの変化 消費税率の変更や手数料自由化など法制度の変化 事務フローの改革や事業所の統廃合 企業合併 企業合併は話が大き過ぎるとしても、取扱商品の変更などにはできるだけ柔軟に対応できるようにしておきたいところである。業務の変化に強いシステム構築のためには、次の4つの考え方が有効である。 変化要素の
ソフトウェアアーキテクトの役割
The Rational Edgeより：もし、ソフトウェアプロジェクトのマネジャーが映画業界用語でいう（作業完了の責任者である）プロデューサーならば、ソフトウェアアーキテクトは（作業を成功させ、最終的に利害関係者のニーズも満たす立場にある）監督だといえる。4回シリーズの2回目となる本稿では、ソフトウェアアーキテクトの役割について解説する。 今回は、ソフトウェアアーキテクチャを説明する4回シリーズの第2回目（第1回目は「ソフトウェアアーキテクチャって何なの？」を参照）となる。第1回目ではアーキテクチャとは何かを明確にした。そこで、今回はアーキテクチャの作成責任者であるアーキテクトについて考える。アーキテクトの役割はおそらく、どのソフトウェア開発プロジェクトにおいても最もその手腕を問われるものだろう。アーキテクトはプロジェクトの技術責任者であり、最終的にはプロジェクトの成否について技術面の責任
ドメイン層に最適なアーキテクチャを考える
前回「階層アーキテクチャの利点は複雑さの減少」は階層化アーキテクチャの考え方について説明してきました。今回は、階層化アーキテクチャにおけるサービス層と、設計が難しいとされるドメイン層についてどのように考えるのかを見ていきます。まず、最初に各層を設計するときに、拡張性・保守性を高めるために何を検討すべきかを考えてみましょう。 （1）業務機能とシステム機能の分離 業務要件を満たすためのビジネスロジックなどを実現する機能とトランザクション制御などシステムを実現するために必要なシステム機能は、別々に実装できるように考えます。ビジネスロジックを実装するコードにトランザクション制御を行うコードが混在することは、拡張性・保守性を著しく悪くします。 （2）層間の依存性の排除 ドメイン層などの階層化アーキテクチャの各層は、基本的に下位層に存在するコンポーネントをブラックボックスとして扱えるように設計します。
ソフトウェアアーキテクチャーって何なの？（後編）
ソフトウェアアーキテクチャーって何なの？（後編）：The Rational Edge（1/2 ページ） 前篇ではソフトウェアアーキテクチャーの定義を詳細に解説した。分かっているようで実は意外とあいまいなままだったソフトウェアアーキテクチャーの本質に少しは迫れたと思う。後篇ではソフトウェアアーキテクチャーの構造をさらに掘り下げる。 前篇ではソフトウェアアーキテクチャーの定義を詳細に解説した。分かっているようで実は意外とあいまいなままだったソフトウェアアーキテクチャーの本質に少しは迫れたと思う。後篇ではソフトウェアアーキテクチャーの構造をさらに掘り下げる。 アーキテクチャーは論理的根拠に基づく判断を具体化する アーキテクチャーで重要な側面は、最終結果だけでも、アーキテクチャー自身でもなく、なぜそのようになるのかという論理的根拠だ。従って、そのアーキテクチャーに結びついた判断と、その判断の論理的
上流工程－「ビジネスモデリング」を基本から理解する---目次
企業がビジネスの目的を実現するには、関係者が勝手な価値観や利害で行動するのではなく、事業目標を共有することが重要だ。そのためには、“ビジネスの見える化”を実現する「ビジネスモデリング」が欠かせない。ビジネスプロセス・モデルを作成する際の基本的な考え方や方法、作成したモデルの活用方法などについて解説する。 ・第１回 なぜビジネスモデリングが大切なのか ・第２回 ビジネスモデリングでは何をモデル化するのか ・第３回 どんな手順・手段でモデルを作るのか ・最終回 作成したモデルをどう生かすのか
Part8 業務の目的と要求――利害関係者を漏れなく洗い出す,目的を構造化して業務要求を定義
Part8では，プロジェクトという視点を加えて利害関係者を考えます。利害関係者の目的とその構造を明確にして業務要求を定義します。要求の優先度は，重要度とリスクを加味した難易度で決定します。 Part8は，演習編の6回目です。Part7までは，業務システムの動的な振る舞いであるプロセスや，業務の静的な構造に着目する演習を解説しました。対象とする業務を様々な視点から分析してきたわけです。 Part8では，対象とする業務そのものだけではなく，業務を改善するためのプロジェクトという視点も考えます。業務は，理想と現実というギャップを抱えています。そして，そのギャップを解消するのがプロジェクトです。すなわち，業務を“問題領域”とすれば，プロジェクトは“解決領域”になります。 Part8の演習の目的は，プロジェクトの利害関係者を漏れなく洗い出し，利害関係者の目的とその構造を明確にした上で，業務レベルの要
Part2 モデリングの全体像――視点を分けて業務要求をとらえ，システム要求を論理的に導く
複雑な物事は，着目する視点を分けて単純化すると理解しやすくなります。まずは業務要求をとらえてから，論理的にシステム要求を導きます。業務とシステムを共通の視点で可視化し，全体の整合性を検証します。 Part1では，モデリングの意義や，そもそもモデリングとはどういうことかなど，モデリングに関する一般的なことを解説しました。 Part2では，演習編に向けての準備として，本講座で実施するモデリングの全体像を説明します。また，本講座では，モデリングの具体的な成果物として，RFP（Request For Proposal：提案依頼書）を取り上げますので，RFPの入門的な知識も解説します。 Part1でも説明したように，RFPはユーザーが作成するものですが，本講座で想定しているレベルのRFPは，実質的にはベンダーのITエンジニアが作成していることが少なくないので，多くのITエンジニアに参考にしていただけ
Part1 モデリング入門――業務全体を“可視化”して顧客をナビゲート，モデリングのスキルが必要不可欠に
Part1 モデリング入門――業務全体を“可視化”して顧客をナビゲート，モデリングのスキルが必要不可欠に 今やモデリングのスキルは，ITエンジニアにとって必須と言えます。Part1では，業務システム分析におけるモデリングの意義を解説します。 業務システムは，業務を効率化してコストを削減するために，広く企業に利用されるようになりました。しかし，膨大な情報化投資を行ったにもかかわらず，結果的には業務の効率化に結びつかず，使われない，あるいは使えないままに放置されているシステムがいたるところにあるのが現実です。 システムを効率よく開発することは重要ですが，間違ったシステムを効率的に開発しても，そのシステムへの投資は無駄になってしまいます。 無駄な投資を抑えるためには，まず業務を経営の構成要素として適切に設計し，その中でシステムを業務の構成要素として開発しなければなりません。つまり，システム要求は
階層アーキテクチャの利点は、複雑さの減少 ― ＠IT
個々のコンポーネントを組み上げて、どのようなシステムを構築するか。構造（アーキテクチャ）によって、できあがるシステムの性質が変わってくる。作り手側の視点に立てば、どのようなアーキテクチャを採用するかによって、作り方も変わってくる。いままで連載した記事を通して、わたしたちは、個々のコンポーネントの作り方を学んできた。今回からは、コンポーネントをいかに組み上げるか、という課題に知恵を絞ることになる。コンポーネントの利点を最大限に生かすこと。それがアーキテクチャ設計の現実的な意味の1つだ。そして、1つの有効なアプローチに階層化アーキテクチャがある。 前回「使いやすくて、変化に強いコンポーネント」までにサブシステムなどを利用したコンポーネントの作り方についてお話ししてきました。それでは、コンポーネントは実際どのような単位で作り上げていけばよいのでしょうか。 コンポーネントの単位として考えられるのは
物の見方や考え方，価値感が一流のSEを作る
第一線のSEにはIT製品スキルやシステム構築力，アプリケーション開発力，プロジェクト管理力，表現力など様々な能力が要求される。そのためIT企業やSEはIT技術やプロジェクト管理，コミュニケーションなどのスキルの向上，各種の資格取得などに熱心だ。 それはそれでよいことだが，筆者の眼から見ると，一般に日本のIT企業やSEは“SEとしての物の見方や考え方や価値感”など精神面をおろそかにし過ぎていると思う。技術面重視・精神面軽視である。 行動は考え方と価値観で決まる 20代30代のSEと称する人の中には，ITスキルだけ強ければ飯が食えると錯覚している人も少なくない。そしてIT企業やSEマネジャもそんな脆弱な心構えしかもっていないSEを指導もしない。そんなSEは顧客からは「SEは冷たい。壁を作る。頼りにならない」などと評されている。 そんな状況を見るにつけ，それでよいのだろうかと疑問に筆者は思う。I
良好なレスポンスを実現するアーキテクチャ ― ＠IT
「ITアーキテクチャ構築の勘所」では、アーキテクチャ設計手順を示し、それぞれのステップにおける勘所を示した。その続編となる本連載は、ビジネス要求に応えるために必要な、「大量トランザクション処理」「24時間365日稼働」「使いやすい」といったシステムの特性に着目し、これを実現するためのITアーキテクチャ構築の勘所を述べていきたい。第1回の今回は「良好なレスポンス」を実現するアーキテクチャについて勘所を示す。 ITアーキテクチャ設計は、ビジネス要求に適切に応えるために、ビジネス要求に即したシステム特性を実現していく作業である。例えば、オンライン証券では多数の照会や売買の要求に対して迅速に応答する必要があり、このためにはクラスタリングやキャッシングをうまく適用したアーキテクチャ設計を行うとよい。 前回の連載では、アーキテクチャ設計手順を示し、それぞれのステップにおける勘所を示した。この続編となる
アーキテクチャ選定のコツは「少し先を見ること」
アーキテクチャ選定のコツは「少し先を見ること」：超現場主義！ 失敗しないITプロジェクトマネジメント（3） 前回「ユーザー企業側プロジェクトマネージャの勘違い」は、「ヒト」に起因するプロジェクトのリスクファクターとその対処法について紹介した。今回は「モノ」に起因するプロジェクトのリスクファクターとして、システムのアーキテクチャとプロジェクトのリスクファクターの関係について紹介していきたい。 ITプロジェクトの現場でよくある風景 開発企業側プロジェクトマネージャ（以下PM） 「今回のシステム提案ですが、ぜひともLAMP（LinuxとApache、MySQL、PHP／Perl／Pythonを組み合わせたオープンソースのアプリケーション構築スタック）を採用したいと思います」 ユーザー企業側PM 「そのアーキテクチャのメリットって何？」 開発企業側PM 「まず、すべて無償なので低コストでシステムを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MSDN ホームページ
ＩＴコンサル養成ギブス−ITコンサルタントになりたい人のサポートサイトです。転職、キャリアアップ、スキルアップを目指せ！
Amazon.co.jp: ソフトウェアアーキテクチャ: アーキテクチャとドメイン指向トラック (ソフトウェアテクノロジーシリーズ): 岸知二, 野田夏子, 深澤良彰: 本
大量トランザクション処理に適したアーキテクチャ ― ＠IT
