We at ZapThink are sure that you are as ecstatic as we are that the whole “2.0″ cliche has finally died down. Web 2.0, Enterprise 2.0, SOA 2.0, the list went on and on. At first a marketer’s dream, but soon a marketer’s nightmare, as the term became so watered down that it lost whatever meaning it originally had.

However, this loss of meaning is perhaps unfortunate, as there truly is an underlying trend in the greater technology marketplace that does distinguish a new wave of innovation (“2.0″) from the earlier wave of a dozen years ago (“dot.com,” rechristened “1.0″ by marketers who love trite consistency). On first glance, this trend centers on collaboration, and it’s quite true that many 2.0 era innovations are collaborative, but that designation misses the point. After all, much of the technology from the 1990s focused on collaboration as well. Remember groupware, knowledge management, and intranets? All collaborative.

Understanding the true root of innovation behind the superficial 2.0 marketing cliche is the secret to today’s software innovation. If you’re an entrepreneur looking for the right idea or hoping to evaluate the idea you have, then this secret is essential to your success. And if you’re in enterprise IT, understanding this secret will enable you to evaluate innovative products coming to market, so that you can separate the ones that will truly provide value from the pack of dot.com also-rans.

A Review of Complex Systems

You can find the secret to true collaborative innovation in Complex Systems Theory. ZapThink has discussed Complex Systems before, in the context of Service-Oriented Architecture and more recently in the context of SOA governance in particular. Essentially, a Complex System is a system that exhibits emergent properties, which are properties of the system as a whole that the components of the system do not exhibit. Complex Systems Theory is particularly fascinating because it describes many natural phenomena, from the human mind to the growth of living creatures to the principle of friction. Furthermore, if you assemble a group of people large enough, they become a Complex System as well, which explains simple emergent properties like a stadium of people doing the wave, to more subtle ones like the wisdom of crowds.

It’s important to realize that Complex Systems are actually systems of systems. The individual elements of a Complex System are themselves systems, which in turn may be Complex Systems in their own right. However, the individual component systems do not exhibit the emergent properties that the larger Complex System will offer.

While a large enough group of people will constitute a Complex System in its own right, for our purposes we’re looking for innovation in Complex Systems that include some software subsystem. Software, however, is not the only subsystem; people must also be a part of the Complex System we’re looking to create. In fact, understanding this basic principle is at the center of the secret to collaborative innovation.

Avoiding the Wrong Approach

Traditional software innovation focuses predictably on traditional systems, as opposed to Complex Systems. To design a traditional system, start with the requirements for that system and build to those requirements. As a result, the best you can expect from a traditional system is that it does what it’s supposed to do.

The emergent properties that Complex Systems exhibit, however, may be unpredictable — at least, before we build the system to see what behavior emerges. The stickiness property of Velcro, for example, is familiar and predictable to us now, but it took a great leap of innovative imagination to look at the little hooks and loops that make up Velcro and see that enough of them put together would give us the stickiness that makes Velcro so useful. The behavior of stock markets, in contrast, is inherently unpredictable, although it does follow certain patterns that give technical analysts something to base their theories on. But if technical analysis really predicted market behavior, there would be a lot more billionaire technical analysts in this world!

The wrong approach, therefore, is to build to a set of fixed requirements, which will tend to eliminate emergent behavior rather than encourage it. This limitation gives startups an advantage, because most traditional information technology (IT) solutions follow traditional systems approaches, which limit their flexibility. For example, traditional integration middleware follows a “connecting things” approach that leads to reduced agility over time, while SOA (properly done, not the fake SOA peddled by the middleware vendors) follows a Complex Systems approach that yields emergent properties like business agility and business empowerment.

So, how do you avoid the wrong approach? Don’t build anything that does what it’s supposed to do. Instead, build something that will lead to surprises. Not every surprise will be useful, to be sure, so you may have to try a few times before you find an emergent property that people will actually appreciate. Also, remember that any system of systems that has component systems that consist solely of technology will most likely be the wrong approach, as the only surprises you’re likely to end up with are bad ones, namely, that it doesn’t even do what it’s supposed to do.

How to Look for an Opportunity

The key to successful collaborative innovation is to realize that humans are part of the system, not just users of the system. While people are unpredictable individually, they are always predictable en masse. Your product development, therefore, must work at two levels. You must think about individual human/technology subsystems as well as the complex human/technology systems that emerge when you have enough of the subsystems in place. Remember, you can influence human behavior at the Complex Systems level by introducing technology at the component system level. To generate emergent properties at the complex systems level, then, you must introduce some element of unpredictability at the component level.

A perfect example of this phenomenon is Twitter. At the component level we have users entering up to 140 characters at a time into a large database that is able to display those tweets based upon various search criteria, the default being your own tweet history. However, if that description were all there was to Twitter, it would never have become the sensation it did. It was the fact that people could follow other people, and that people realized they could use hash tags to designate keywords and “at” people with the “@” symbol that introduced an element of unpredictability into the behavior of the individual user/Twitter subsystems. Scale that up to millions of users, and you have the emergent properties inherent in Twitter trending and other aspects of the Twitterverse that make Twitter such a fascinating tool.

Other examples of successful Complex Systems innovations include:

• SOA governance — human activity-centric governance processes supported by a metadata-driven infrastructure enable SOA implementations to exhibit the business agility emergent property.
• Viral marketing — one person uses a viral marketing tool to tell his or her friends about something cool in a way that encourages them to do the same, leading to the emergence of popularity across large populations.
• Semantics tooling — our computers aren’t smart enough to understand the meaning of data, so to effectively automate semantic integration requires human/software subsystems, which lead to the emergence of automated semantic context.
• Crowdsourcing — Ask a random person to do something or provide information and there’s no telling what you’ll get. But use a crowdsourcing tool to ask enough people, and you’ll get the emergent property of the wisdom of crowds, where the crowd is able to arrive at the correct answer or solution.
• Anything with the network effect — One fax machine or Facebook when it had one user are entirely useless. Two fax machines or Facebook with two users are almost entirely useless. Up the number to three, four, five…still pretty damn useless. But at some point, there’s a critical mass of users that makes the solution valuable, and you get the emergent property that more people want to join all of a sudden, where before they didn’t.

The ZapThink Take

Our core advice to entrepreneurs, therefore, is to come up with a simple tool that is simple when you put it in front of individual users, but yields some kind of unpredictable behavior that when scaled up to large numbers of people delivers an emergent property that people will value. Keep in mind, however, that you hope to be surprised by the result. It may or may not be an emergent property that people will end up wanting, and thus may not be the basis for a viable business model. There is an inherent element of experimental innovation involved, which makes product development inherently risky. On the plus side, however, that risk gives you a barrier to entry, especially from large vendors who sell predictability.

The Complex Systems we’re describing are inherently collaborative, because you’re including people in the system, and the unpredictability you seek results from allowing them to interact in some way. But remember, the converse is not necessarily true: not all collaborative systems are Complex Systems. Any multi-user application in the enterprise, for example, is collaborative on some level, but if the vendor didn’t build the right unpredictibility into it, then it won’t exhibit emergent properties. Those sorts of tools don’t deserve the “2.0″ appellation. To create a truly innovative collaboration-based solution in today’s software environment, you must create a Complex System.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

رأى زاب ثينك

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

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

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

Read more at: IT Business Edge