On two occasions I have been asked,—”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

—Charles Babbage, 1864

The long-standing computer science principle of “garbage in, garbage out” (GIGO) is so fundamental to IT that it predates digital computing by almost a century. And yet here we are in the twenty-first century, moving to the Cloud, and Babbage’s exasperated response is no truer or more on point. For not only is the Cloud a magnet for all sorts of garbage, it is also generating new garbage at a brisk clip.

Uploading Garbage to the Cloud

In today’s frantic rush to “move to the Cloud,” too many organizations are failing to ask what they should move to the Cloud. Instead, they envision the Cloud as some kind of huge, nebulous server in the sky, a perfect receptacle for  whatever they have on-premise. Got email? Put it in the Cloud! Got data? Put your data in the Cloud, the bigger the better! Running business processes on-premise? Move them to the Cloud!

Not so fast. Let’s slow down a bit and consider the ramifications of moving too quickly—and haphazardly—to the Cloud.

• Unclean data – This is the obvious example, pure GIGO. If your current on-premise data are unclean, say you have inconsistent customer demographic information, or obsolete product information, or any other data quality challenge, it goes without saying that moving such information to the Cloud won’t do your data, or your business, any good.  Instead, think of moving your data to the Cloud as though you were moving your elderly parents to a condo. It’s a wonderful excuse to finally dig through the layers of detritus so that you only move data that are clean, accurate, and valuable to the business.

• Spaghetti code – you may be eyeing that old custom-coded legacy app as a prime Cloud candidate. It’s too slow, it doesn’t scale well, and it’s a bear to integrate now, so won’t the Cloud automatically make it fast, scalable, and easy to integrate? Sorry to burst your bubble. If you’re focusing on an IaaS approach, what you’ll find is that spaghetti code is every bit as intractable in the Cloud as it is on-premise. What about PaaS? Chances are that old code won’t run at all. Today’s PaaS environments expect and enforce a certain level of code quality.

• Obsolete and Cloud-unfriendly business processes  –  Does this sound familiar? The business asks IT to automate a set of processes, but states unequivocally that “the processes are fine the way they are. Automate them but don’t change them. After all, we’ve been doing things the same way for years. Why change now?” Yes, the business often says that, but seasoned IT veterans have long realized that the business never actually means it. When the business asks IT to touch a process, there is always at least an implied requirement to try to make it better: faster, more streamlined, better aligned with the underlying business need.

Moving business process implementations to the Cloud raises the stakes in this complex dance between business and technology, because the Cloud offers a wealth of new opportunities for improving processes. Furthermore, how users interact with Cloud-based assets is often fundamentally different from how users interact with traditional enterprise apps. Any organization that has moved from an older CRM app (or no CRM app at all) to Salesforce.com has learned this lesson first hand. But Salesforce is merely a harbinger of greater change to come. One of the main reasons Salesforce has been so successful is because they offer their clients new ways of conducting business—in other words, better processes. Any SaaS solution should build on their example.

Generating New Garbage in the Cloud

The garbage problem doesn’t end with garbage you might put in the Cloud. The Cloud also presents numerous opportunities to generate new kinds of garbage.

• Zombie instances – it’s so easy and cheap now for anyone in your organization to spawn their own Cloud instances, including virtual machines, storage instances, and more. Furthermore, such instances are elastic: need more of them? The Cloud is only too happy to oblige. But what happens when you’re done with them? You’re supposed to delete them. After all, elasticity works in both directions. All too often, however, instances that have served their purpose are left around like so much space junk. After a while, nobody remembers what they’re for or if they still have something important in them. The last thing you want to do is delete an instance with valuable data or code on it. So to play it safe, you leave it around. Forever. Your Cloud provider is only too happy to keep billing you for these Zombie instances.

• Data with no provenance – any Antiques Roadshow aficionado knows that antiques with provenance are more valuable than those without. The same goes for your data. Do you know if the data you’re working with are the latest version? Do you know they haven’t been tampered with? If not, then those data are worse than useless, since they may be incorrect, or even worse, keeping them around may violate any number of regulations. Here again the elasticity of the Cloud works against you.

• Manual or poorly abstracted configurations – Let’s say you’ve built a sophisticated Cloud app based on elastic VM instances. If you need more, simply provision more. But then let’s say some admin somewhere in your IT shop goes into one of these instances and changes a config file in order to get an app to run on that instance. Now you have no way to update your instances without breaking your app—and if that admin didn’t tell anybody about the reconfiguration, then tracking down the problem will present a time-consuming challenge.

Simply creating a static image file to generate new VM instances—and keeping rogue admins from monkeying with them—won’t solve the problem, because there is more to your app than the instances. Instead, you need a next generation configuration management approach that automates configuration for the Cloud. See Chef or Puppet for an indication where this market is going. (You can expect a ZapFlash on Cloud configuration management in the near future.)

• Cloud-unfriendly architecture choices – We covered one example of this problem in our ZapFlash The Secret to a RESTful Cloud: stateful Cloud instances. Essentially, inappropriate state information is just more garbage in the Cloud. Another example would be inappropriate transactionality in the Cloud. Cloud Computing lends itself to particular ways of architecting applications, and attempting to shoehorn the wrong architectural approach into the Cloud is about as effective as Cinderella’s stepsisters’ efforts with the glass slipper.

The ZapThink Take

How do you avoid garbage in the Cloud? Architecture is a large part of the answer, of course, but governance is equally important. Organizations should establish and enforce Cloud-centric policies as well as extending current IT governance to the Cloud. With great power comes great responsibility, and the Cloud offers enormous new power to many different roles within the IT organization. The Cloud is fraught with pitfalls. Without sufficient governance, you’re bound to fall in one.

It is also important to note that the issues in this ZapFlash apply equally to private as well as public Clouds. Organizations generally realize that public Clouds present numerous governance challenges, and look to private Clouds because they are ostensibly less risky. But such a stance offers little more than a false sense of security—one that may backfire, if organizations assume that in the absence of proper architecture and governance, a private Cloud is the better choice. Don’t wait to implement adequate Cloud governance until after you’ve run into these problems. Governance should be an integral part of any Cloud strategy, before you move to the Cloud.

ترجمة: وائل الخواص – 7 ديسمبر 2009 (http://wael.elkhawass.com)

Arabic Translation for the ZapFlash article “Is there a Future for Enterprise Software?”

يمكنك قراءة المقال من خلال هذا الرابط

غالبا ما يتبادر الحديث ضمناً عن دور ومستقبل التطبيقات البرمجية المؤسسية عند الحديث عن البنية القائمة على الخدمات (إس أو أيه). ففى الواقع فإن زاب ثينك تتحدث منذ سنوات بشكل أو بآخر عن مستقبل التطبيقات البرمجية المؤسسية. إذاً فلماذا يسلط الضوء على هذا الموضوع مرة أخرى الآن وفى هذا المنعطف؟ هل تم رصد أى تغيير فى السوق؟ هل تم الكشف عن إجابة جديدة عن هذا السؤال: إلى أين ستؤدى التطبيقات البرمجية المؤسسية. ستكون الإجابة على هذين السؤالين بالإيجاب وربما قد حان الوقت للتحرك بجدية والعمل على كل النقاط التى نتحدث عنها منذ فترة.

إن العامل الأساسى الأول هو الإندماجات المهمة الذى تم رصدها مؤخراً فى السوق بين التطبيقات البرمجية المؤسسية. فمنذ عقد أو أكثر كان هناك عشرات من الشركات الكبيرة التى توفر حزم متعددة من هذا النوع من التطبيقات. أما الآن فقد أصبح هناك عدد ضئيل من الشركات الكبيرة التى توفر هذا النوع من التطبيقات بالإضافة لعدد آخر محدود من الشركات الطموحة التى توفر تطبيقات موجهة لصناعات بعينها. ويمكننا إسناد الفضل فى هذا التغيير للأنشطة المتعلقة بعمليات الدمج و الإستحواذ و ما صاحبها من إجراءات ضغط وترشيد النفقات على تكنولوجيا المعلومات. وقد ترتب على هذه الإندماجات الإستغناء عن عدد كبير من حزم التطبيقات المؤسسية (ومثال على هذه الحزم تطبيقات تخطيط الموارد المؤسسية أيه آر بى و تطبيقات إدارة علاقات العملاء سى آر إم وتطبيقات إدارة الموردين إس سى إم) فإنه إن لم يكن قد تم الإستغناء عن هذه التطبيقات بالفعل فإنها فى طريقها للسحب تدريجيا أو سوف يتم دمجها مع تطبيقات وحلول أخرى.

تقوم الكثير من الشركات بتبرير إنفاق ملايين الدولارات على التطبيقات البرمجية المؤسسية بأن تكلفة هذه التطبيقات تُسترد بمرور عقد من الزمن أو أكثر من إستخدامها ويمكن الإدعاء بأن هذه التطبيقات تكون أرخص بمرور الوقت من بناء التطبيقات وإدارتها خصيصا لهذه الشركات، ولكننا قابلنا الكثير من الحالات التى تدعونا للإقتناع بأن هناك عوامل كثيرة تجعلنا نعيد التفكير فى هذه المبررات منها حاجة التطبيقات البرمجية المؤسسية للتجميع الكلى بين حين وآخر والحاجة للإنفاق المستمر و كذلك عدم مرونة هذه التطبيقات.

فبالإضافة إلى ما تم ذكره حتى الآن فإن هناك أسباب أخرى لتباطؤ إعتماد التطبيقات البرمجية المؤسسية و لتباطؤ جهود التكيف معها أو تهيئتها للعمل مع التقنيات التى تعكس تغيراً مستمرا لصورة تكنولوجيا المعلومات. من هذه الأسباب الأهمية القصوى لتلك التطبيقات وتأثيرها البالغ فى بيئة عمل المؤسسات وكذلك الصعوبة الكبيرة التى تتسم بها هذه التطبيقات. نحن نطلق على هذه الحالة مصطلح “الإنقسام الرقمى داخل المؤسسات”. عندما يمكنك الحصول كمستخدم لخدمات تكنولوجيا المعلومات على مستوى متقدم من خبرة الإستخدام عند استعمالك لشبكة المعلومات فى منزلك أو عند استعمالك للتطبيقات الشخصية على جهاز حاسوبك أو التطبيقات المتقدمة على هاتفك المحمول بينما تحصل على خبرة إستخدام أسوأ بكثير فى مكان عملك. يولد لديك هذا الإختلاف إحساسا بأن التطبيقات المستخدمة فى مكان عملك متأخرة بعقد كامل عن التقنيات المتقدمة التى تستعملها بسهولة على مستوى استخداماتك الشخصية. يرجع السبب في ذلك إلى النقص الكبير فى الإبداع فى البرمجيات المؤسسية إلى التكلفة المرتفعة والمجهود الكبير المطلوبين لتعديل و تطوير هذه التطبيقات ذات الإقتران الوثيق بين مكوناتها.

وبالإضافة إلى ذلك أيضا — فإنه لا توجد شركة تقوم بشراء و تنفيذ تطبيق برمجى مؤسسى “على الحالة التى يباع بها”. لا تقوم الشركات بإنفاق أموال طائلة على تعديل وتربيط التطبيقات البرمجية المؤسسية التى تقوم بشرائها فحسب ولكنها تنفق أيضا مبالغ كبيرة على إنتاج برمجيات تكتب خصيصا لدعم الترابط مع هذه التطبيقات ودعم الإعتمادية عليها.
وما قد يبدو لك أنه تطبيق برمجى مؤسسى قائم بذاته يكون فى الواقع فوضى متشابكة ناتجة عن تطبيق معين تم شرائه من بائع واحد لأداء وظيفة محددة مضافاً إليه تعديلات ذات إعتماد بينى وثيق ومجموعة من التربيطات وبرمجيات كتبت خصيصا لربط هذه الفوضى ذات المكونات المتنوعة. فى الواقع أنه عندما تطلب من الناس أن يصفوا لك هيكلية مؤسساتهم (إى أيه) غالباً ما يشيرون إلى تلك الفوضى المعقدة و الخطيرة من التطبيقات البرمجية المؤسسية الذين قاموا بشرائها وتعديلها وصيانتها. لا يمكننا بأى حال من الأحوال اعتبار ذلك هيكلية مؤسسية. بل يمكن اعتباره رضيعاً قبيحاً لا يحبه أحدٌ غير أمه.

ومع ذلك تؤكد لنا الشركات بصفة مستمرة إعتمادهم الكامل على بضعة تطبيقات يستخدمونها فى عملياتهم اليومية. تخيل ماذا سيحدث لأى شركة كبيرة إذا خرج من السوق بائعهم الوحيد الذى حصلت منه على تطبيق تخطيط الموارد المؤسسية (أيه آر بى) أو تطبيق إدارة علاقات العملاء (سى آر إم) أو تطبيق إدارة الموردين (إس سى إم) يمكن للشركة حينها أن تضطر أن تتوقف نهائياً عن العمل.

بينما يصر البعض على أهمية التطبيقات البرمجية المؤسسية التجارية ذات البائع الواحد فإننا فى المقابل يمكننا تأكيد كم اللا منطقية فى إعتماد الشركات موقف كهذا مع أنه يعتبر مركزاً وحيداً للفشل. إنه لمن السخف بمكان الإعتماد على منتج واحد و بائع واحد للقيام بكل عمليات الشركات فى بيئة تكنولوجيا المعلومات، حيثما لا يوجد سبب تقنى وجيه يفسر وجود هذه الإعتمادية. فكلما زاد اعتمادك على شىء وحيد فى نجاحك كلما قلت مقدرتك على التحكم فى مستقبلك.

لا يمكن تحديد مصير الإبتكار فى الشركة بسهوله عندما تكون الشركة معتمدة على قدرة شركة أخرى على الإبتكار. ولأننا جميعا نعلم السرعة الكبيرة التى أصبح عليها الإبتكار فى الوقت الحالى فإننا نرى فى ذلك علامات تحذيرية ضخمة.

خدمات ، سُحُب ، مزج: لماذا تشترى تطبيق برمجى مؤسسى؟

قد تحدثنا فى مقالات سابقة من زاب فلاش عن كيفية ظهور الخدمات على نطاق من مستويات متباينة وكذلك التطورات المتلاحقة فى تقنيات تقديم الخدمات بعدم الإعتمادية على المكان أو على المنصة وتقديمها حسب الطلب وتقديمها بصور متغيرة. تم تعزيز ذلك كله عن طريق مبدأ السُحُب. كذلك سوف يغير ظهور التقنيات الغنية التى تسهل وتسرع من تجميع الخدمات من الطريقة التى ترى بها الشركات بناء و إدارة التطبيقات. بدلاً من شراء التطبيق و تعديله وتربيطه سوف يكون التطبيق فى أى لحظه هو المشهد الحالى التى يعبر عن الخدمات المختلفة التى تم تجميعها لتحقيق طلبات المستخدم المتاحة فى وقت التنفيذ. ومن هذا المنطلق فإن التطبيق البرمجى المؤسسى لن يكون ما تشتريه ولكن ما الذى تستطيع عمله باستخدام ما لديك.

هناك نتيجة يمكن استنباطها من هذا المنظور لماهية التطبيق البرمجى المؤسسى و هو أنه يمكن للشركات الآن تحويل نفقات رخص إستخدام التطبيقات البرمجية المؤسسية ومصاريف صيانتها (والتى تأتى بالفعل على جزء كبير من ميزانيات تكنولوجيا المعلومات) إلى نفقات تطوير الخدمات و استهلاكها و تجميعها. هذا ليس فرقاً فلسفياً فحسب ولكنه فرق حقيقى. فبينما أنه من المؤكد أن الخدمات تقوم بتعريض قدرات موجودة بالفعل ولذلك فإنك لا تزال تحتاج لهذه القدرات الموجودة عند بناء الخدمات. إن التحول للبنية القائمة للخدمات (إس أو أيه) يعنى أنه يتم مكافأتك عند تعريض وظائف توجد لديك بالفعل بينما فى الحالة التقليدية للتطبيقات البرمجية المؤسسية يتم معاقبة الأنظمة المتوارثة بسبب التكلفة الملازمة للترابط معها. إن التحول للبنية القائمة على الخدمات (إس أو أيه) يقوم بمكافأة الأنظمة المتوارثة لأنك لا تحتاج لبناء ما لديك مرة أخرى.

فى هذا السياق، إذا كان لديك ما تحتاجه وقد قمت بشراءه من بائع، فإن عليك الإحتفاظ به. ولكن يجب عليك ألا تنفق أموالاً أخرى على نفس الخصائص الوظيفية. بل قم بإنفاق الأموال على تعريض واستهلاك ما تحتاجه لتحقيق الطلبات الجديدة. هذا ما ينبغى الإهتمام به، الهيكلية المؤسسية الجيدة وليس التطبيق البرمجى المؤسسى الجيد.

لقد قامت التركيبة الناتجة من مجموع تعريض خدمات الأنظمة المتوارثة واستهلاك خدمات مقدمة من طرف ثالث والإعتماد على الخدمات المتوفرة على السُحُب (وهنا نقصد كل ما هو متوفر على السُحُب من بيئة تحتية أو منصات أو برمجيات) بتحفيز الفكرة القائمة على مبدأ أنه لو لم يكن لديك بالفعل أياً من حزم التطبيقات البرمجية المؤسسية المقدمة عن طريق بائع واحد فإنه من المحتمل أنك لن تكون محتاجاً لأحد هذه التطبيقات. يوجد لدينا تجارب مباشرة مع شركات جديدة بدأت عملياتها ونمت لتصل إلى بضعة ملايين من الدولارات دون الحاجة إلى إنفاق سنتاً واحداً على التطبيقات البرمجية المؤسسية. وبالمثل فقد رأينا شركات بقيمة مليارات الدولارات تتخلى عن استثماراتها فى التطبيقات البرمجية المؤسسية أو أنها تبدأ العمل فى أقسام جديدة لها ولعملياتها فى بلدان جديدة دون الحاجة لتوسيع الرخص الخاصة باستخدام التطبيقات البرمجية المؤسسية التى لديها. عندما تقوم بسؤال مسئولى التكنولوجيا فى هذه الشركات عن التطبيقات البرمجية المؤسسية المستخدمة فى شركاتهم سوف يجيبونك بالإشارة ببساطة على مجموع الخدمات التى لديهم مضاف إليه التطبيقات المعتمدة على السُحُب و كذلك البنى التحتية الداعمة لهذا الترابط.

يمكن للبعض الإصرار على أن التطبيقات المعتمدة على السُحُب وتلك التطبيقات التى يطلق عليها تطبيقات البرمجيات كخدمة ما هى إلا تطبيقات برمجية مؤسسية موحدة تم تدشينها على البيئة التحتية الخاصة بشركة أخرى. ربما تكون هذه هى الحال فى الماضى بالفعل فى نطاق التطبيقات المقدمة مما هو معروف بشركات توفير خدمات التطبيقات (أيه إس بى) أو تطبيقات البرمجيات كخدمة ولكن هذه لم تعد الحال الآن. لقد تطور أداء هذه الحلول فى العقد الماضى بأن أصبحت مكونة من خدمات ذات اقتران سهل يزيد من القيمة المضافة لهذه البيئات والتى أصبحت تبدو و كأنها قائمة تسويقية (كتالوج) من القدرات المنفصلة و المتنوعة أكثر من كونها تطبيقات كاملة. هل تريد أن تقوم ببناء موقع شبكى وتحصل على بيانات عن الزبائن المحتملين، لا يوجد أدنى مشكلة، ما عليك إلا أن تحصل على الخدمة الصحيحة من سيلز فورس أو من أى موفر آخر للخدمة وفق اختيارك و قم يتربيطهم باستخدام تقنيات خدمات الشبكة العنكبوتية أو تقنية نقل تمثيل الحالة (ريست) أو نهجك القياسى المعتاد والنتيجة هى عدم تكبدك أموالاً طائلة فى سبيل هذا العمل.

مقارنة بين التطبيقات مفتوحة الشفرة و التطبيقات التجارية و بناء تطبيقاتك بنفسك

هناك اتجاه جديد يشير إلى تباطؤ نمو التطبيقات البرمجية المؤسسية و هو ظهور بدائل من التطبيقات مفتوحة الشفرة. تُقبل الشركات بشدة حالياً على حلول مثل ويب إيه آر بى وكذلك الطبعة المجتمعية من شوجار سى آر إم والحلول الأخرى التى لا تتطلب رخصة استخدام أو تكاليف صيانة وتقوم بتوفير 80% من الخصائص الوظائفية لحزم البرمجيات التجارية. وبينما يشير البعض إلى تكاليف الدعم الفنى لهذه الحلول نشير نحن فى المقابل إلى الفارق الجوهرى بين الدعم الفنى من جهة و تكاليف رخص الإستخدام و الصيانة من جهة أخرى. فعلى الأقل فى الحالة الأولى يمكنك معرفة المقابل الذى ستحصل عليه بإنفاق أموالك. إنه لمن الصعب بمكان تبرير إنفاق الملايين من الدولارات على تكاليف رُخَص الإستخدام على الرغم من استعمالك ل 10% أو أقل من إمكانيات المنتج.

إن من الجوانب المهمة التى تعزز قيمة اعتماد التطبيقات مفتوحة الشفرة هو أن هناك مطورون آخرون يقومون ببناء قدرات إضافية فوق هذه الحلول ويقومون بدورهم بالتبرع بالحلول الناتجة. هذه الطبيعة الخاصة للتطبيقات مفتوحة الشفرة تساعد على خلق قدرات جديدة تعتبر قيمة مضافة للمنتج. هناك نقطة معينة يمكن اعتبارها نقطة تحول لمنتج مفتوح الشفرة عندما يتخطى حجم التحسينات التى تمت عليه أى امكانيات يمكن لأى بائع منفرد أن يقدمها فى منتجه. ببساطة عندما يقوم مجتمع المطورين بدعم الجهود المبذولة فى تطبيق مفتوح الشفرة تكون النتيجة تفوق إبتكارى ملحوظ على أى منافس من المنتجات التجارية.

فيما بين التطبيقات مفتوحة الشفرة والتطبيقات التجارية و تقنيات “البرمجيات كخدمة” من خلال السُحُب، أصبح للشركات خيارات موثوق بها لبناء التطبيقات البرمجية المؤسسية الخاصة بها. يوجد الآن أجزاء ومقاطع كثيرة متوفرة مجانا أو بأسعار زهيدة مما يمكن الشركات من تجميع ليس فقط حلولاً تتسم بالعمل بكفاءة ، ولكن تتسم أيضاً بقدرتها على التوسع بطريقة تمكنها من منافسة الكثير من الحلول التجارية. بنفس الطريقة التى استطاعت شركات فى السابق أن تستغل لغة ميكروسوفت فيجوال بيسك لبناء تطبيقات باستخدام الآلاف من أدوات التحكم المجانية أو رخيصة الثمن والتى تم إنتاجها بواسطة أعداد هائلة من المطورين. يبدو الحال مماثلاً تماماً عندما نلاحظ الإتجاه إلى استخدام أدوات خدمية مجانية أو رخيصة الثمن والتى يمكنها تكوين تطبيقات معقدة و متينة.

مستقبل التطبيقات البرمجية المؤسسية التجارية

ليس من الواضح فى الوقت الحالى إلى أين تنطلق التطبيقات البرمجية المؤسسية التجارية. بالتأكيد لا يبدو المشهد وكأن الشركات سوف تتخلى نهائياً فى وقت قريب عن التطبيقات الراسخة فى بيئتها، ولكننا لا نرى كذلك أى سبب لتوسعة مبيعات هذه التطبيقات. بطريقة ما أصبحت التطبيقات البرمجية المؤسسية صورة من صور الأنظمة المتوارثة هذه التطبيقات أن تحل محلها و التى تعمل على الحاسبات العملاقة والتى مازالت موجودة بوفرة فى بعض الشركات. لقد أدرك بعض منتجى التطبيقات البرمجية المؤسسية أن عليهم التوجه بسياسة مبيعاتهم تماماً من مجال حلول التطبيقات الكاملة إلى مجال بيع أدوات خدمية تركيبية. لا يريد هؤلاء المنتجون بالطبع أن يحلقوا خارج السرب وأن يكونوا خارج منظومة الأعمال الجديدة. إنهم بالتأكيد لا يريدون أن يبيعوا لك القطارات لتنتقل من مكان لآخر فحسب ولكنهم يريدون أيضاً أن يبيعوا لك القضبان إن استطاعوا.

هناك حالات كثيرة تبدو فيها فكرة التعامل مع التطبيقات البرمجية المؤسسية كمنصة وكأنها لعبة رهان. بدلا من أن تنفق الملايين على تطبيق بعينه يمكنك على النقيض صرف تلك الملايين على شراء بيئة تحتية تأتى معها أدوات خدمية مضبوطة مسبقاً. يبقى السؤال : هل تستحق تكلفتها تلك البيئة التحتية المعروفة فقط لمنتجها التى تحصل معها على مجموعة من الأدوات الخدمية؟ هل قمت بالتضحية ببعض معايير الإقتران السهل للخدمات فى سبيل حصولك على “عنق واحد جاهز للخنق”؟ إن معظم سوق التطبيقات البرمجية المؤسسية يسير فى اتجاه تصادم مباشر مع بائعى البيئات الوسيطة الذين يريدون أن يدخلوا سوق التطبيقات. بينما يبدأ الكثيرون من بائعى التطبيقات البرمجية المؤسسية برؤية منصتهم التشغيلية فى اتخاذ موقف دفاعي، وسوف يبدأون أيضا فى التعارض مع استراتيجيات الهيكلية المؤسسية والتى تسعى الى إزالة أى اعتمادية على بائع وحيد. إننا نرى أن هذه المنطقة سوف تكون الأكثر توتراً خلال السنوات القليلة القادمة. ماذا عنك؟ هل تريد أن تكون متحكماً فى بيئتك التحتية وأن يكون لديك الإختيار؟ أم تريد أن تترك التحكم فيها لبائع وحيد والذى يمكن أن يكون ناتجا عن عملية دمج أو تعثر نتجت بدورها عن اختفاء الشركة المنتجة الأصلية أو تحولها إلى نوع آخر من الأعمال.

رأى زاب ثينك

نحن نتمنى أن يستعمل هذا التقرير من زاب فلاش كنداء قوى للحد من سخف “التطبيقات” التى تكلف الملايين من الدولارات و تكلف ملايين أخرى لتعديلها لأداء جزء من الذى نحتاجه. فى هذه الفترة التى يستمر فيها الضغط المالى عليها فإن آخر ما يجب على الشركات فعله أن تستثمر أكثر فى تقنيات خرجت إلى العالم فى سبيعينيات القرن الماضى و بلغت الرشد فى تسعينياته وبدأ أداؤها فى الهبوط للأسوأ منذ ذلك الحين.

إن الإعتماد على حزم التطبيقات البرمجية المؤسسية العملاقة والتى يتم توفيرها من خلال بائع واحد لن تقدم يد المساعدة ولكنها على النقيض سوف تعيق خطوات الحصول على بنية قائمة على الخدمات تتميز بالإقتران السهل و الرشاقة والتجانس والقدرة على التركيب. لقد آن الأوان للشركات أن تسحب رهاناتها وتعيد حساباتها فى الأموال التى تنفقها على التطبيقات البرمجية المؤسسية وأن تسثمرها فى نوع ما من الهيكلية المؤسسية الحقيقية والتى تهتم قليلاً بشراء الأشياء بشكل كلى وما يتبع ذلك من عمليات تعديل و تهيئة ولكن تهتم كثيراً ببناء و تركيب و إعادة استعمال ما تحتاجة بطريقة متكررة لكى تستجيب للتغيرات المستمرة.

و كأننا نثبت وجهة نظر، يمكن الإشارة إلى أن سهم شركة إس أيه بى قد تحرك هابطاً اليوم بنسبة 10% بسبب هبوط أرباحه. هناك من يقوم بإلقاء اللوم على الحالة العامة للإقتصاد ولكننا نشير إلى هذه الكتابات الموجودة على الجدران والتى تقول: لقد تم بيع كل التطبيقات البرمجية المؤسسية التى يمكن أن تباع وأن الظروف التى تحتم شراء و تنفيذ رُخَص استخدام جديدة هى فى الواقع ظروف قليلة و متباعدة. قم باستثمار أموالك فى هيكلية مؤسسية بدلاً من الإنفاق على تطبيقات برمجية مؤسسية ، و على الخدمات بدلاً من التعديل ، و على السُحُب بدلاً من بنية تحتية لا يمكن توقعها. قم بذلك و سوف تكون أحسن حالاً.

The first major factor is significant consolidation in the marketplace for enterprise software. While a decade or so ago there were a few dozen large and established providers of different sorts of enterprise software packages, there are now just a handful of large providers, with a smattering more for industry-specific niches. We can thank aggressive M&A activity combined with downward IT spending pressure for this reality. As a result of this consolidation, many large enterprise software packages (such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM) offerings) have been eliminated, are in the process of being phased out, or are getting merged (or “fused”) with other solutions. Many companies rationalized the spending of millions of dollars on enterprise software applications because the costs could be amortized over a decade or more of usage, and they could claim that these enterprise software applications would be cheaper, in the long run, than building and managing their existing custom code. But, we’ve now had a long enough track record to realize that the result of mass consolidation, need for continuous spending, and inflexibility is causing many companies to reconsider that rationalization.

Furthermore, by virtue of their weight, significance in the enterprise environment, and astounding complexity, enterprise software solutions are much slower to adopt and adapt to new technologies that continuously change the face of IT. We refer to this as the “enterprise digital divide.” You get one IT user experience when you are at home and use the web, personal computing, and mobile devices and applications and a profoundly worse experience when you are at work. It’s as if the applications you use at work are a full decade behind the innovations that are now commonplace in the consumer environment. We can thank expensive, cumbersome, and tightly-coupled customization, integration, and development for this lack of innovation in enterprise software.

In addition, no company can purchase and implement an enterprise software solution “out of the box”. Not only does a company need to spend significant money customizing and integrating their enterprise software solutions, but they often spend significant amounts of money on custom applications that tie into and depend on the software. What might seem to be discrete enterprise software applications are really tangled masses of single-vendor functionality, tightly-coupled customizations and integrations, and custom code tied into this motley mess. In fact, when we ask people to describe their enterprise architecture (EA), they often point to the gnarly mess of enterprise software they purchased, customized, and maintain. That’s not EA. That’s an ugly baby only a mother could love.

Yet, companies constantly share with us their complete dependence on a handful of applications for their daily operation. Imagine what would happen at any large business if you were to shut down their single-vendor ERP, CRM, or SCM solutions. Business would grind to a halt. While some would insist on the necessity of single-vendor, commercial enterprise software solutions as a result, we would instead assert how remarkably insane it is for companies to have such a single point of failure. Dependence on a single product, single vendor for the entirety of a company’s operations is absolutely ludicrous in an IT environment where there’s no technological reason to have such dependencies. The more you depend on one thing for your success, the less you are able to control your future. Innovation itself hangs in the balance when a company becomes so dependent on another company’s ability to innovate. And given the relentless pace of innovation, we see huge warning signs.

Services, Clouds, and Mashups: Why Buy Enterprise Software?

In previous ZapFlashes, we talked about how the emergence of Services at a range of disparate levels combined with evolutions in location- and platform independent, on-demand, and variable provisioning enabled by Clouds, and rich technologies to facilitate simple and rapid Service composition will change the way companies conceive of, build, and manage applications. Instead of an application as something that’s bought, customized, and integrated, the application itself is the instantaneous snapshot of how the various Services are composed together to meet user needs. From this perspective, enterprise software is not what you buy, but what you do with what you have.

One outcome of this perspective on enterprise software is that companies can shift their spending from enterprise software licenses and maintenance (which eats up a significant chunk of IT budgets) to Service development, consumption, and composition. This is not just a philosophical difference. This is a real difference. While it is certainly true that Services expose existing capabilities, and therefore you still need those existing capabilities when you build Services, moving to SOA means that you are rewarded for exposing functionality you already have. Whereas traditional enterprise software applications penalize legacy because of the inherent cost of integrating with it, moving to SOA inherently rewards legacy because you don’t need to build twice what you already have. In this vein, if you already have what you need because you bought it from a vendor, keep it — but don’t spend more money on that same functionality. Rather, spend money exposing and consuming it to meet new needs. This is the purview of good enterprise architecture, not good enterprise software.

The resultant combination of legacy Service exposure, third-party Service consumption, and the Cloud (*-as-a-Service) has motivated the thinking that if you don’t already have a single-vendor enterprise software suite, you probably don’t need one. We’ve had first-hand experience with new companies that have started and grown operations to multiple millions of dollars without buying a penny of enterprise software. Likewise, we’ve seen billion-dollar companies dump existing enterprise software investments or start divisions and operations in new countries without extending their existing enterprise software licenses. When you ask these people to show you their enterprise software, they’ll simply point at their collection of Services, Cloud-based applications, and composition infrastructure.

Some might insist that Cloud-based applications and so-called Software-as-a-Service applications are simply monolithic enterprise software applications deployed using someone else’s infrastructure. While that might have been the case for the ASP and SaaS applications of the past, that is not the case anymore. Whole ecosystems of loosely-coupled Service offerings have evolved in the past decade to value-add these environments, which look more like catalogs of Service capabilities and less like monolithic applications. Want to build a website and capture lead data? No problem — just get the right Service from Salesforce or your provider of choice and compose it using Web Services or REST or your standards-based approach of choice. And you didn’t incur thousands or millions of dollars to do that.

Open Source vs. Commercial vs. Build your Own

Another trend pointing to the stalling of enterprise software growth is the emergence of open source alternatives. Companies now are flocking to solutions such as WebERP, SugarCRM Community Edition, and other no-license and no-maintenance fee solutions that provide 80% of the required functionality of commercial suites. While some might point at the cost of support for these offerings, we point out the factor of difference between support and license / maintenance costs. At the very least, you know what you’re paying for. It’s hard to justify spending millions of dollars in license fees when you’re using 10% or less of a product’s capabilities. Enhancing this open source value proposition is that others are building capabilities on top of those solutions and giving those solutions away as well. The very nature of open source enables creation of capabilities that further value-adds a product suite. At some point, a given open source solution reaches a tipping point where the volume of enhancements far outweighs what any commercial vendor can offer. Simply put, when a community supports an open source effort, the result can out-innovate any commercial solution.

Beyond open source, commercial, and software-as-a-Service cum Cloud offerings, companies have a credible choice in building their own enterprise software application. There are now a lot of pieces and parts available that are free, cheap, or low cost that companies can assemble into not only workable, but scalable offerings that can compete with many commercial offerings. In much the same way that companies leveraged Microsoft’s Visual Basic to build applications using the thousands of free or cheap widgets and controls built by the legions of developers, so too are we seeing a movement to free or cheap Service widgets that can enable remarkably complex and robust applications.

The Future of Commercial Enterprise Software Applications

It is not clear where commercial enterprise software applications go from here. Surely, we don’t see companies tearing out their entrenched solutions any time soon, but likewise, we don’t see much reason for expansion in enterprise software sales either. In some ways, enterprise software has become every bit the legacy they sought to replace in mainframe applications that still exist in abundance in the enterprise. Smart enterprise software vendors realize that they have to get out of the application business altogether and focus on selling composable Service widgets. These firms, however, don’t want to innovate their way out of business. As such, they don’t want to just provide the trains to get you from place to place, but they want to own the tracks as well.

In many ways, this idea of enterprise software-as-a-platform is really just a shell game. Instead of spending millions on a specific application, you’re instead spending millions on an infrastructure that comes with some pre-configured widgets. The question is: is the cost of the proprietary runtime infrastructure you are getting with those widgets worth the cost? Have you lost some measure of loose coupling in exchange for a “single throat to choke?” Much of the enterprise software market is heading in direct collision course with middleware vendors who never wanted to enter the application market. As enterprise software vendors start seeing their runtime platform as the defensible position, they will start conflicting with EA strategies that seek to remove their single-vendor dependence. We see this as the area of greatest tension in the next few years. Do you want to be in control of your infrastructure and have choice, or do you want to resign your infrastructure to the control of a single vendor, who might be one merger or stumble away from non-existence or irrelevance?

The ZapThink Take

We hope to use this ZapFlash to call out the ridiculousness of multi-million dollar “applications” that cost millions more to customize them to do a fraction of what you need. In an era of continued financial pressure, the last thing companies should do is invest more in technology conceived of in the 1970s, matured in the 1990s, and incrementally made worse since then. The reliance on single-vendor mammoth enterprise software packages is not helping, but rather hurting the movement to loosely-coupled, agile, composition-centric heterogeneous SOA. Now is the time for companies to pull up the stakes and reconsider their huge enterprise software investments in favor of the sort of real enterprise architecture that cares little about buying things en masse and customizing those solutions, but building, composing, and reusing what you need iteratively to respond to continuous change.

As if to prove a point, SAP stock today slid almost 10% on missed earnings. Some may blame the overall state of the economy, but we point to the writing on the wall: all the enterprise software that could be sold has been sold, and the reasons for buying or implementing new licenses are few and far between. Invest in enterprise architecture over enterprise software, Services over customizations, and Clouds over costly and unpredictable infrastructure and you’ll be better off.

Architecture and the Utility Services Cloud
Most of the time, when people point to practical, in-production examples of cloud computing efforts, they are talking about the sorts of utility services offered by Amazon.com, Google, Salesforce.com, and others. The Services offered in these clouds are not built with any particular application in mind, but rather whole categories of applications. For obvious reasons, these cloud providers seek to leverage economies of scale by serving the largest possible audience using a handful of highly reusable Services, where reuse is defined by usage in multiple contexts. For these cloud providers, the utility Services simultaneously provide a source of revenue as well as a platform their customers use to replace proprietary, in-house infrastructure and middleware.

Given that the emphasis of these Services is to meet the needs of a large and continuously growing audience who have diverse requirements, the utility cloud provider’s primary focus is placed on infrastructural concerns. As a result, it’s the infrastructure technologists who are in charge of this cloud. When the “architecture team” meets in these cloud providers, what problems are they aiming to solve? Business problems? Certainly not. In most cases, the architecture teams for these providers (of which we’ve been privy to a number of conversations), focus almost exclusively on technology and infrastructural concerns. Key conversations revolve around performance optimization, implementation change management, optimizing the balance between efficiency and cost, meeting reliability and uptime concerns, and addressing privacy, security, and governance issues.

Where’s the business in all this? The answer: nowhere. Where should the business be in all this? That’s a tough question to answer because without Service consumers, the cloud wouldn’t exist at all. However, it is not the goal of the cloud provider to meet any specific business requirements. Rather, the requirements are aggregated to create a business “persona” that is the focus of continual Service releases. In this manner, one could argue that there are no enterprise architects providing any value in this environment. The most pervasive form of architecture done in these environments is more akin to Information Technology Infrastructure Library (ITIL) approaches rather than any form of enterprise architecture (EA). Utility clouds are the domain of infrastructure experts, not business-IT gap bridgers or process modelers, and one could argue that this status quo will probably never change.

Architecture and the Application (Process) Cloud
However, the utility Service vision of the cloud is not the only one. Indeed, we’re starting to see the emergence of application and process clouds that provide the same infrastructural and economic benefits of clouds, but applied to process-specific concerns. These cloud providers enable the outsourcing of entire processes that run in a virtualized cloud environment as a way of handling variability in scale. For example, an insurance company can use a cloud provider’s claims processing Service when their internal capacity is not sufficient to meet demand. As long as the process is Service-oriented, this approach works well and leverages the strength of the cloud’s abstract infrastructure capability while staying focused on the process. This way, an organization can have its internal processes augmented by third-party cloud processes. For example, insurance clouds provide elastic capabilities for insurance applications as demand ebbs and flows. Likewise, banking, supply chain, retail, and other process-specific clouds provide cloud computing benefits for specific groups of business users.

In this environment, the cloud provider needs to balance two different, but equal concerns: infrastructural issues of the sort described above, and the challenge of meeting continuously changing business requirements. When application-specific cloud provider architect groups meet, their conversations look very different from utility Service cloud providers. Rather than focusing on infrastructural issues as they try to meet the common denominator of needs (“speeds and feeds”), the conversation usually revolves around how the team will meet new business process requirements given the existing set of Services and infrastructure. In many ways, these teams have a true EA conversation: the continuously changing and diverse business requirements on the one hand, and the technical capabilities on the other. These EA conversations invoke aspects of Agile Methodologies and EA frameworks more so than ITIL. Rather than trying to minimize the set of business processes handled by the cloud, they seek to continuously expand the universe of processes addressed.

As we often discuss in our Licensed ZapThink Architect (LZA) SOA training courses, the job of the enterprise architecture team is to optimize the conceptual equation of producing the smallest set of Services that meet the largest number of business processes. You don’t want to produce too many Services, otherwise there’s waste. Likewise, you don’t want to produce too few Services as that constrains the number of business processes you can address. As new Services are introduced, the universe of business processes addressed likewise increases. Since application / process-specific cloud providers are businesses that must justify their existence by staying focused on the business without impacting existing operations. Sounds like something all enterprise architect teams should do, no?

The ZapThink Take
In many ways, the discussion of architecture has been given short shrift in cloud computing conversations. In much the same way that the Service-Oriented Architecture (SOA) conversation degenerated into a conversation about the (often unnecessary) Enterprise Services Bus (ESB), the cloud conversation is degenerating into one about the infrastructure needed to handle scalable Service provider volume. And where is the conversation about the business process? Unless you are planning to build a general-purpose Service provider cloud to compete with the likes of Amazon.com and others, you should be focused on where the opportunity is: in the process. And to focus on the process while keeping an eye on the technology requires an enterprise architecture perspective.

The mistake that many cloud-consuming companies are making is that the cloud is giving them an excuse not to think about enterprise architecture at all. The thought going through the head of many a supposed architect is: “whew, thank goodness we’re putting this in the cloud so that I don’t have to invest in architecture.” Wow, what a mistake. These companies will be in for a rude awakening when they realize that all they’ve done is shifted their internal mess, which at least they have some control and visibility over, to an external mess that they have less control over. Enterprise architecture doesn’t go away simply because someone else is hosting or providing your Services. Organizations that want to have any chance of improving their agility, flexibility, reliability, and performance need to be in charge of their own architecture. There is no other option.

Given that too few cloud computing providers have your business in mind when they architect their solutions, and the ones that have a process-specific business model and approach aren’t concerned with your specific business, it lands upon the laps of enterprise architects within the organization to plan, manage, and govern their own architecture. Once again, the refrain is that SOA is not something you buy, but something you do. Perhaps we can start hearing the same mantra with cloud computing? Or will the cloud succumb to the same short-sighted, market pressure that doomed the ASP model and still plagues SaaS approaches? It’s not up to vendors to answer this question. It’s up to you… the enterprise architect. There are no short-cuts to EA.

Read more at: CRM Mastery

Read more at: Intelligent Enterprise

Read more at: Apex Developer Network Blog