システム間連携について
今考えている事を休み明けに実行に移すためにメモしておく。
ある程度の規模の会社になると業務の種類*1に応じて様々な仕組み（システム）が乱立していると思う。
そのそれぞれが同じようなアーキテクチャやプロットフォームで作られているなんて事はまずありえないわけで、開発言語でさえも統一されていない。データベースなんかのミドルウェアも同様。
「これから作っていくシステムは合わせていきましよう」なんて言うのは簡単で何とでもなるわけだけど、今あるレガシーな仕組みはどうするの？って話になってくる。
もう何十年も動いている仕組みなんてのはざらで、ユーザも全社的に散らばっていて、少しでも変更を加えようものなら混乱は必至。リプレイスなんて夢のまた夢、いったいどれだけのコストがかかるのか計り知れない。
そいうった仕組みが自分の周りにもいくつかあって、これがあまりにも使いにくくてどうにかならないかと常々考えていた。
だからといって使いやすくしようにも先程のような理由で仕組み自体に手を入れるような事は実質的に不可能な状態。それらの仕組みが何かしらの外部インターフェースでも持っていれば、そこから使いやすいフロントエンドを自作する事も可能だけど、インターナルな業務システムにはそんな気の効いたものはついていないので不可。
そんな事を考えながら、その使いにくい仕組みをぶつぶつ文句言いながら使っていたんだけど、今日なんとなく思い立ってその仕組みにPowerShellからアクセスしてみた（その仕組みはWebの仕組みなのだ）。
独自の認証機構を持っているので、ちょっと面倒くさそうだったけど案外簡単にできて作業時間の一覧を取得するところまでできた（その仕組みは勤怠システムなのだ）。
それをやってみた思ったのはWebベースで動く仕組みなら、そこでやっていることは所詮ただのHttpリクエスト／レスポンスなので、いくらでもプログラムでエミュレートできるということ（当たり前なんだけどね）。
じゃあこんな感じで既存の仕組みにアクセスするためのWebベースのAPIを仕組み毎に作ってやれば、それぞれをマッシュアップとか独自のフロントエンドを作ったりだとかが比較的楽にできるんじゃね？なんて事を思った。
もちろん生のHTMLをパースしてデータを取り出していくわけだから、オーバーヘッドも高いし、画面レイアウトを少しでも変えられただけでぶっこわれるけど、まず変更される事がないような仕組みならそんなに心配することはないと思う。
それに既存の仕組みに対していっさい変更を加えなくても、その資産を活用し新しく使いやすい仕組みを作れる事はずっと価値があるんじゃないの？って思った。
だから、休み明けに「スケジュール管理システム」と「勤怠管理システム」にWebベースのAPIを用意してやって、それぞれをマッシュアップしてイカス仕組みを作ってやろうと思う。
一つ残念なのは、これを作ってもWebに公開できないということかな。まぁ汎用的なノウハウだけは公開できると思うので、そのへんは公開していきます。
これも一つのSOAの形だよね？
