fbpx

ソリューションアーキテクチャーデザイン連載(13/13):データソリューションアーキテクトサービス(DSAS)とは何ですか?

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

「データソリューションアーキテクトサービス(DSAS)」とは、弊社独自のソリューションアーキテクチャー設計サービスであり、お客様のデータ活用の速度向上をサポートすることを目的としています。我々が最も重視している価値は「スピード」です。このサービスは、独自のアプローチと手法で、お客様のデータ活用を最適化することを追求しています。

元々「ソリューションアーキテクチャー」とは、システム全体のアーキテクチャーを設計するために、ビジネス側のニーズや技術要件、アーキテクチャースタイル、プラットフォームなどを総合的に考慮したアプローチを用いる概念です。これには、組織の目標や戦略、利用可能な技術、現在および将来のビジネス環境など、さまざまな要素を踏まえた上で、最適なシステム構成や機能要件を明らかにし、効率的な情報システムを構築することを目指しています。

弊社のデータソリューションアーキテクトサービスでは、データ活用においてネイティブクラウド、イベントドリブンアーキテクチャー、サーバレスアーキテクチャー、マイクロサービス、アジャイル手法などを駆使し、高速かつ高品質なデータ活用を促すソリューションを提供しています。

「図:データソリューションアーキテクトサービスのフロー」に示されるように、クラウド上の様々なツールに熟練したエンジニアが、お客様のビジネスプロセスをヒアリングし、お客様と共に最適なアーキテクチャー案を作成します。その後、お客様の合意を得てフーィジビリティ検証(PoC)を実行し、お客様のデータをワンパス通して確認します。最終的には、環境やソースコード、課題レポートなどを製品開発チームに引き継ぎ、必要に応じて製品開発においても継続的にお客様の成功を応援します。

我々のサービスは「図:データソリューションアーキテクトサービスのイメージ」のように表現することができます。現代においてクラウドは非常に強力なツールですが、同時に非常に複雑な技術でもあり、利用に際してはビジネスプロセス、ハイアベラビリティ、スケーラビリティ、セキュリティ、運用監視のような機能性を利用者がニーズに応じて設定しなければなりません。これは、クラウドで提供されるマネージドサービスに詳しいだけでは不十分であり、多様なアーキテクチャースタイルに精通し、お客様のビジネスプロセスに最適なマッピングが必要です。

改めて「図:データソリューションアーキテクトサービスのイメージ」を見ていただきたいですが、我々はクラウドサービスやビジネスプロセスを建築のための「材料」、最終的な製品を「建物」と位置づけています。そして、両者の橋渡しを高速かつ高品質で提供することを我々の使命としています。

データソリューションアーキテクトサービス(DSAS)の中身は、ビジネスプロセスを理解し、各種クラウドサービスやNoSQL、アーキテクチャースタイルに精通しているアーキテクトが参加するアーキテクチャーの設計、お客様とアーキテクトとの間で合意が取れたアーキテクチャーでプロトタイプを作成し、お客様のデータをワンパス通して確認する実現可能性の検証(PoC)、最終的に製品開発チームに提供される環境とソースコード、課題レポートなどから構成されます。

 

  • アーキテクチャー設計
  • 実現可能性検証(PoC)
  • プロトタイプ・課題レポート

 

具体的なソリューションアーキテクチャー設計の方法論については、「別紙:ソリューションアーキテクチャーデザインパターン」を参照してください。

我々は、システム開発を「実現可能性の検証(PoC)」と「製品開発」のフェーズに分けて進めることを提案しています。あるビジネスプロセスを想定したアーキテクチャーを設計し、実際にプロトタイプを作成し、実現可能性を検証することは、大きな意味を持ちます。それによって成功が担保され、大きな失敗が回避できます。

「図表:実現可能性の検証フェーズと製品開発フェーズの比較」で見るように、実現可能性の検証フェーズと製品開発フェーズでは、必要なスキールセットや専門知識のレベルに大きな差があります。

実現可能性の検証フェーズでは、アーキテクチャー設計に関わる技術のエキスパートが必要です。製品開発フェーズでは、開発手法や言語的な技術のエキスパートが必要です。2つのフェーズを分けることによって、それぞれのフェーズの成果を最大に引き出すことができます。

我々のサービスでは、実現可能性の検証フェーズの成果物は、開発チームに引き継がれ、ビジネスプロセスの実装及び運用向けのリファクタリングを加えながら製品に仕上げていきます。実現可能性の検証フェーズと製品開発フェーズを分離することで、非常に効率的な製品開発が可能になります。

実現可能性の検証フェーズ 役割:アーキテクチャー設計、プロトタイプ作成、PoC
技術:エキスパート
短期間
製品開発の前段階
少数精鋭
製品開発フェーズ 役割:コーディング、テスト、運用実装
技術:プログラム言語、業務
長期間
製品開発からリリース
比較的に大人数

[図表:フィージビリティ検証フェーズとプロダクト開発フェーズの比較]

 

 

前のページへ|Topページへ

Author

モダンアーキテクチャー基盤のソリューションアーキテクトとして活動しています。

[著書]
・Amazon Cloudテクニカルガイド―EC2/S3からVPCまで徹底解析
・Amazon Elastic MapReduceテクニカルガイド ―クラウド型Hadoopで実現する大規模分散処理
・Cypherクエリー言語の事例で学ぶグラフデータベースNeo4j
・Neo4jを使うグラフ型データベース入門(共著)
・RDB技術者のためのNoSQLガイド(共著)

leeの記事一覧

新規CTA