Изпълнение на вашия SOA като уеб стартиране

Една от по-забележителните разлики между ИТ и онлайн света в наши дни е контрастът между традиционното предприятие ориентирана към услугата архитектура и неговия еквивалент в мрежата, отворени API. Все повече и повече уроци идват от онлайн пространството, предоставяйки ключови прозрения за това как можем да активизираме начина, по който отваряме нашите ИТ системи за максимална стойност.

SOA няма същата бизнес спешност и липсва критичен фокус в това отношение в повечето организации. Така че докато показват някои нови данни че 75% от всички големи предприятия ще използват SOA до края на тази година (а 60% дори ще бъдат разширяването му), най-очевидните успехи с подходи, ориентирани към услугите, не са класическите организации изобщо. Те са уеб компании, които предлагат API от основна необходимост: бързо и евтино изграждане на мрежа от партньорства, както и използване на външни иновации и евтини инвестиции от трети страни.

Бърз преглед на Google News показва няколко полезни нови публични уеб услуги (известни още като отворени API), които бяха обявени тази седмица, включително една за Bing на Microsoft както и от по-малки компании като Училищен кръг, който току-що стартира API че "позволява на системите за класиране и оценяване да изтеглят данни - като списъци и задачи - от School Loop и записвайте резултати в дневника с оценки на School Loop за показване на родители, учители, ученици и други заинтересовани страни." И двата API позволяват на всеки и навсякъде да създава приложения, които взаимодействат със и включват съответните им възможности.

Това са само два типични примера за повече от 40 нови API, пуснати в света само през последните 30 дни, според Програмируемо табло за API на Web, в момента най-надеждният източник на такава информация. Това темпо на освобождаване е доста стабилно: A "глобална SOA“ расте около нас в мрежата.

Джо Маккендрик наскоро попита тук в ZDNet ако имаме нужда от iTunes модел за уеб услуги. Реалността е, че той вече съществува -- макар и в удобна за мрежата, проста форма -- а не в провалените визии на UDDI директории от миналото, но в прагматичното пускане на стотици и стотици нови API всяка година.

SOA и отворени API: близки братовчеди

Също така е вярно, че SOA инициативите в големите компании обикновено не обявяват публично своите вътрешни разработки, така че е много по-трудно да се добие представа какво се създава и използва в повечето организации. Въпреки това е доста ясно, че има някои значителни разлики и резултати между тези два подхода за отворени услуги, въпреки че те привидно имат едни и същи цели на лицето на това: Да насърчи оперативната съвместимост между различни бизнес системи и да предостави възможности, които иначе биха били твърде трудни, скъпи или отнемащи време улавяне.

Това, което е особено интригуващо за тези две страни на една и съща монета, са вродените предположения, които те правят: SOA обикновено е режийни усилия (смята се, че може да се направи и на място) между ИТ и бизнеса, което в крайна сметка позволява на бизнеса да постигне подобрени резултати и дори случайни резултати, когато става дума за интегриране и ливъридж на съществуващи инвестиции в системи и данни. Възвръщаемостта на инвестициите много често е трудна за измерване и бързите подобрения в бизнеса обикновено не са норма. SOA също са склонни да бъдат по-насочени навътре и предназначени за вътрешно потребление.

Сравнете това с отворените API, в които API се счита за основно стратегическо предимство за бизнеса. Гледката е, че инвестицията в разработването на API е оправдана поради непосредствените ползи, които могат да бъдат получени: увеличен обхват до нови клиенти в мрежата, използване на външни иновации, увеличени инвестиции от трета страна и мащабируем модел за трета страна отношения. Интересното е, че колкото по-голяма е организацията, толкова по-голяма стойност може да предложи API на съществуващи и потенциални партньори, главно поради данните са склонни да бъдат по-богати и по-ценни и/или функционалността, която излага, е от световна класа чрез успеха на включването бизнес. Това е визия, при която ориентиран към услугата бизнес канал (отворени API, а не уеб страници) често се превръща в доминиращ канал за взаимодействие с техните клиенти както може би има за пазарни лидери като Amazon, Twitter и други. За разлика от повечето SOA усилия, API също са склонни да бъдат проектирани за потребление от по-широкия свят, въпреки че със сигурност се използват и вътрешно.

Би било грубо опростяване да се каже, че SOA е технически подход за решаване на изключителен набор от бизнес проблемите и отворените API са бизнес решение, което използва технически подход, но все повече това изглежда е случай. Преди няколко години попитах дали е така моментът беше подходящ за бизнеса да се отвори към облака особено след като почти мнозинството от ИТ директорите настояваха за това. За повече предприятия това просто не се е случило, оставяйки стратегически пропуски в изпълнението, което помогна да доведе до скорошните дискусии за възможността за тихата смърт на SOA.

Тези точки подчертават ключова разлика между целите и стратегиите на SOA и отворените API. Отворените API са за бизнеса, преди всичко, чрез привличане на разработчици за изграждане на полезни нови неща, които са взаимни благотворно. При създаването на много консумативен и ценен набор от услуги уеб компаниите се надяват да привлекат с течение на времето кумулативните усилия на екосистема от разработчици и техните съответни бизнеси. Това е класическата стратегия за „превръщане на приложение в платформа“, която е успешна за водещите Web 2.0 компании: SOA прави същото с различен фокус, които съм обсъждал тук в този блог вече няколко години. Успехът на API модела е ясен: Обратно само преди година имаше само 700 API в глобалната SOA. Днес те са почти двойно повече, близо 1400. Заедно те осигуряват гръбнак от услуги, в които може да се намери почти всякакъв вид услуга които компаниите могат да използват, за да създадат най-богатите и конкурентни продукти и услуги за своите клиенти.

Отворен бизнес, който създава стойност: Две перспективи

И така, в крайна сметка, ако цялата тази отвореност, партньорство и оперативна съвместимост в мрежата е толкова добра за нас, къде пропускаме по отношение на изграждането на бизнеси, ориентирани към услуги? Този въпрос е особено уместен за предприятието, където напоследък SOA често се възприема като предоставяща слаби резултати. За да добия представа за проблемите, помолих две добре известни фигури в съответните им области да ни дадат допълнителна перспектива.

Първо се свързах Бъртън ГрупАн Манес, уважаван авторитет в корпоративната SOA, централна фигура в дебати за бъдещето на SOA, и по мое мнение уравновесен глас на разума относно технологиите и бизнеса, който я моли да обобщи накратко какво е необходимо, за да направи SOA успешна за един бизнес. Тя даде този отговор:

ИТ организациите трябва да осъзнаят, че SOA не е крайна цел. SOA е средство за постигане на цел: предоставяне на системи, които са по-управляеми, гъвкави и гъвкави. Но основната цел трябва да бъде подкрепата на постоянно променящите се нужди на бизнеса. ИТ групите трябва да отделят по-малко време за фокусиране върху технологиите и инфраструктурата и вместо това да се фокусират върху предоставянето на системи (известни още като услуги), които осигуряват измерима бизнес стойност.

След това отидох при Орен Мишелс, главен изпълнителен директор на Mashery.com, водеща фирма, която помага на големи компании като Netflix, MTV, Най-добра покупка, и Световната банка доставят отворени API на своите вътрешни и външни клиенти и го помолиха за същото. Ето какво каза той:

Доставчиците на уеб услуги се възползват от създаването на канал за разпространение на техните основни услуги. Малко компании имат като своя основна компетентност създаването и управлението на канал за дистрибуция и рядко една компания може да развие канала си толкова бързо, колкото иска. Възползването от обхвата на партньорите, които включват вашите уеб услуги, ви позволява да се съсредоточите върху подобряването на тези услуги - с други думи, фокусиране върху това, което ви отличава.

Така че независимо дали сте доставчик или потребител на уеб услуги, всичко се свежда до фокус - вие изграждате, управлявате и управлявате неща, които ви определят и отличават и правят тези уеб услуги мощни, надеждни, мащабируеми, сигурни и брониран. Предоставянето на тази стойност ще ви плати. Изграждането и пускането на неща, които са достъпни другаде, ще доведе до загуба на фокус, което е пряк път към провал.

И двете гледни точки подчертават една и съща основна точка: бизнес стойността е на двигател за успеха на услугите в една организация, точка. Както Ан, така и Орен независимо друг от друг използваха думата „фокус“ ​​като ключов разграничител за успеха на канал, ориентиран към услуги (или SOA, или отворен API). Гледната точка на Орен обаче беше още по-крайна; в онлайн свят, където липсата на ангажираност не означава просто неуспешно начинание за услуги, това често означава край на вашата бизнес, оцеляването все повече зависи от възможността да предоставите привлекателен набор от услуги за вашите най-важни клиенти; вашите бизнес партньори.

Много показателно е, че Twitter все още получава 10 пъти повече използване чрез своя API от партньори, отколкото чрез своя уеб интерфейс и това съотношение не е необичайно. Също така е много необичайно нов уеб продукт да стартира без API; услугите са пътят към успеха в днешната мрежа, където ако имате нещо ценно, трябва да се уверите, че има лост. SOA няма същата бизнес спешност и липсва критичен фокус в това отношение в повечето организации.

Накратко, традиционната корпоративна SOA има какво да научи от отворения свят на API. Не всички резултати са впечатляващи, но има много отлични примери и това е част от все по-спешния призив за отворени бизнес модели и без способна и здравословна екосистема за услуги, която функционира добре в отворената мрежа, организациите са все по-неизгодни в уеб-ориентирана свят.

Как SOA могат да вземат уроците от отворените API и да ги прилагат, за щастие, средствата са прости и са малко по-бизнес ориентирани, отколкото технически. И накрая, някои SOA наистина правят тези неща, но твърде много пропускат възможностите, пред които са изправени.

Как да стартирате своя SOA като уеб стартиране

1. Лесна употреба. Превръщането на услугите в консумативи от всяка платформа, инструмент или език за програмиране е жизненоважно за приемането на API, когато клиентите ще използват всички местни инструменти, които имат на свое разположение. Традиционните SOA често използват по-сложни, по-малко удобни за уеб технологии, които затрудняват взаимодействието, освен ако търговските партньори не използват много подобен набор от инструменти. В мрежата, използвайки изключително прости, високоефективни модели като REST или WOA са често срещани и лесно се използват за създаване мешапи. Много API предоставят референтни реализации, инструменти за тестване и дори Уеб джаджи които са готови за внедряване с изрязване и поставяне (например Google Maps), за да сте сигурни, че имат предимство. Предоставя се и много документация и поддръжка.
2. Отчитане/фактуриране. Уверете се, че клиентите разбират какво струва това, насърчават се да консумират ресурсите разумно и могат измервайте и вижте какво използват, гарантира разумно и подходящо използване на услугите с положителна обратна връзка цикъл. Той също така често предоставя бизнес модела за API, въпреки че много от тях просто са щастливи да получат трафик, инвестиции или иновации. В SOA това може да е модел на връщане на плащане от някакъв вид вътрешно (жизненоважно за извършване на потребление управляеми и отговорни), но за търговските партньори може наистина да бъде директна сметка или друго компенсация.
3. Управление на профила. Всички отворени API са силно свързани с това кой ги използва и се използват за предоставяне на обслужване на клиенти, проследяване на използването и създаване на отчетност. Също така е от съществено значение за нивата на качество на обслужване за различни класове клиенти и други по-сложни мерки. В допълнение към идентифицирането на всички заявки (и защитата на API), акаунтите също позволяват идентифицирането и ограничаването на лошо поведение на партньори. Модел на акаунт за клиенти е първокласен гражданин в API.
4. Самообслужване. Един от ключовите аспекти на публичните API е, че те могат да се използват без продължителен процес на преговори и партньорство между компаниите. Това е по-важно, отколкото изглежда, тъй като прави възможно придобиването на много повече партньори по-бързо и рентабилно, отколкото е възможно иначе. Регистрацията, лицензирането, интегрирането и тестването, както и плащанията са автоматизирани и онлайн за повечето API, което прави възможно една компания да работа със стотици или дори в някои случаи (като Salesforce, Amazon, Google и други) стотици хиляди API клиенти на рентабилен начин. API за самообслужване позволяват много лека интеграция, при която партньорът върши почти цялата работа за интегриране с вашата система; един доставчик на API просто трябва да създаде добре документиран, мащабируем API, изграден и платен веднъж, вместо да се ангажира с много усилия за интегриране на трети страни.
5. Общността на разработчиците. API зависят от предоставянето на изключително привлекателна и използваема опция, която разработчиците да приемат. Ако първоначалното доказателство за концепциите успее, API се превръща в бизнес отношения. Поради тази причина повечето API полагат големи усилия, за да привлекат и задържат разработчиците, които често ще вземат дългосрочно решение дали набор от услуги е жизнеспособен за използване, следователно API, който не се грижи добре за своите разработчици, трябва да има най-добрите данни или данни от единствен източник или способност. Днес в мрежата е стандарт да има пълноценна общност на разработчици с екип за поддръжка, форуми, проследяване на проблеми и всички атрибути на продукт за разработчици. Без да предоставят на разработчиците инструментите и информацията, от които се нуждаят, за да успеят, е трудно за a бизнес за изграждане и разчитане на чужди услуги, особено когато въпросите и проблемите не са разрешено. Това подчертава ориентирания към клиента характер на отворените API и SOA има абсолютно същите изисквания, въпреки че обикновено има по-малко формалности в поддръжката на разработчиците. Обърнете внимание, че по-големите доставчици на API дори имат персонал за маркетинг/евангелизиране на пълен работен ден, който насърчава разработчиците да научете и консумирайте техните предложения за услуги, вместо да преоткривате колелото и да го изграждате себе си. За SOA това би било достигане до вътрешни бизнес звена, както и до партньори на трети страни.
6. Честен лиценз. Освен ако доставчикът на API не предостави някакво разрешение за използване на функционалността и данните в друг бизнес, има малък стимул за другите да допринасят със своите ресурси и иновации за създаване на нови продукти, включващи това API. Идеален лиценз е този, който дава разрешение на потребителите на API услуги да използват повторно неговите възможности при управлението на техния бизнес ще осигурят законната възможност за използване на API по толкова гъвкав начин, колкото възможен. Същото и със SOA; Виждал съм повече от една SOA, където вътрешните бизнес звена не харесват използването на техните данни другаде в организацията и го спират. Това ще убие бизнес стойността на услугите и е грешен фокус.

Има и други важни аспекти на отворените API, като например управление (ограничаване на скоростта, одити на сигурността, управление на версиите) и споразумения за ниво на обслужване, но те са по-лесно разбрани от днешните предприятия. Но за тези, които се стремят да направят услугите си по-критични за бизнеса, дори жизненоважни за крайния резултат (вижте страхотния графика на приходите от Amazon), точките по-горе изброяват много от разликите между услугите, които стимулират стойността, и услугите, които недей

Нововъзникващата бизнес среда на Мрежата предостави тежки уроци за онлайн компаниите, които трябва да оцелеят в суровия и пропадащ свят на Интернет, чрез всякакви възможни техники. По пътя изглежда, че това все повече се е доказал като модел за услуги, който съдържа много трудни уроци за SOA, а именно: 1) Нашата бизнес визия и партньор обхватът на SOA се нуждае от значително подобрение и 2) отварянето към облака ще бъде ключова следваща стъпка за много фирми, които търсят пълната стойност от своите инвестиции. Тези уроци продължават да идват и скоро ще разгледаме някои истории, включително облачни изчисления/SOA, новия семантичен уеб и други в предстояща публикация.

Как извличате бизнес стойност от вашата SOA? Моля, добавете коментари в Talkback по-долу и ще направя всичко възможно да отговоря на всеки коментар.