Enterprise 2.0: Top 10 Reasons NOT to Use WOA & APIs

Share your find
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Enterprise 2.0 Strategy for Platform Architecture

Intranet vs Internet

The main goal of a winning Enterprise 2.0 Strategy is to facilitate communication and innovation through collaboration.  The Art of Enterprise Architecture in E 2.0 is to unite people and process.  Thoughts on Enterprise 2.0 Architecture include leveraging the principles of Service-Oriented Architecture (SOA) to support Web-Oriented Architecture (WOA).  This type of Internet architecture for the Intranet makes is possible to support Web 2.0 Apps, Gadgets, & Widgets in the Enterprise.  This strategy reduces the number of resources required for the technical part of Enterprise 2.0 Architecture and provides time to focus on Improving Enterprise 2.0 Adoption Through Gamification.

Many organizations today are supporting employee collaboration through Enterprise 2.0 Platforms.  Vendors are also providing Enterprise 2.0 Solutions that include Social Networking features very similar to Facebook and Twitter.  Some organizations and vendors are missing the biggest success factor behind these popular Social Networking Platforms.  The Application Programming Interface (API) of these platforms contributed heavily to their success.  Using APIs to easily link data is the foundation of how the internet works today.  Enterprise 2.0 platforms should provide a great user experience, enable third-party developers and empowers employees to accomplish their business objectives. This can be accomplished with an Enterprise 2.0 solution that leverages Web-Oriented Architecture (WOA) with open, standards-based, non-proprietary API implementations built on web-based RESTful architecture.

Enterprise 2.0: Top 10 Reasons NOT to Use WOA & APIs

  1. We have endless resources and enjoy spending extra money on integration.
  2. We like to spend our bonus money on infrastructure to support bloated code.
  3. We have no desire to support multiple devices.
  4. We have no plans to share information across multiple environments.
  5. We don’t want a platform that can be extended.
  6. We want to pay top dollar for things most get for free.
  7. We don’t support Standards because we enjoy watching our bug list grow.
  8. We believe code should be rigid and not reusable.
  9. We understand the benefits of WOA & APIs, but that’s not the way we do things here.
  10. We feel trendy when talking about OSGI bundles for the Enterprise Service Bus (ESB).

Data.Gov Demonstrates the Power of WOA and APIs

The next-generation Data.gov platform delivers a fantastic citizen experience, enables developers and empowers agencies to accomplish their mission.  See how this is accomplished in this video.

What Does It Mean to API-Enable Data.Gov?

The Web-Oriented Architecture (WOA) of Data.Gov offers an open, standards-based, non-proprietary API implementation built on web-based RESTful architecture. Learn more here [pdf].

Happy Fav Five Friday!

Favorite 5 Places

Forrester: SOA thriving; but interest in ESBs slips A new survey of 2,165 companies, compiled by a team led by Forrester Research’s Randy Heffner, finds that interest in service oriented architecture remains strong, despite today’s emphasis on cloud computing, mobile applications, and social networking …more

Enterprise 2.0 Roll-up: Welcoming Service Cloud 3 and iPad Remember when Chatter first came out? Salesforce.com’s CEO Marc Benioff couldn’t stop talking about how it was just like Facebook. This week that level of social functionality has been extended to Service Cloud 3, the newest iteration of the company’s social …more

5 recommendations for successfully implementing distributed innovation and shared value The real reason for distributed innovation is simply that you can no longer be self-sufficient. You must bring together more and better resources than you can hope to have inside a single organization. This means that distributed innovation models must address how … more

Becoming an Open Leader Two years ago I posted a short post that picked up from an HBR article on leadership flaws.  I posed the question if Enterprise 2.0 initiatives can thrive in environments where toxic leadership reigns.  My first reaction was no, and then I thought about ways to get to yes.  One of the flaws of flawed leadership is the lack of feedback — to gain self-awareness there is a problem in the first place.  Perhaps the feedback loop E2.0 cultures …more

#E2sday: How to Calculate the ROI of Enterprise 2.0 With enterprise social software platforms starting to gain widespread traction, ROI measurements are now becoming possible with early adopter communities. Many companies are looking for a detailed guide on how to measure the benefits of E2.0 …more [infographic]

6 thoughts on “Enterprise 2.0: Top 10 Reasons NOT to Use WOA & APIs”

  1. That was something different than I expected.
    Although your points are valid, for some reason the whole implementation of WOA often gets stuck at the solution design level where current architects are just under-educated on online tech and architecture. As such there is still so much battles to be fought even though the benefits of having WOA style architectures.

    Important 11 and 12 to add in my opinion would be:
    – We don’t need the business to be in control, that might just be to effective.
    – We don’t need more than 6-8 releases a year. We are perfectly fine telling the business they have to wait for 12 weeks for their changes to go live, when they miss a QA deadline.

  2. Arnoud,

    Thanks for sharing your thoughts about Web-Oriented Architecture (WOA) here. I agree about the current struggle, especially at the solution design level. Web Developers and Designers are quickly learning how to leverage these techniques to create more flexible User Interfaces. This is a newer way of thinking about offering an Intelligent User Interface (IUI) for multiple device clients and will require time to master. The IUI should also be smart enough to know how to save system resources by leveraging the processing power of the client device.

    I hope more development teams adopt your additional tips about releases. I believe Development Teams and Business Teams should collaborate together and create an effective strategy for managing expectations. Defining QA as a REAL task in the development process will help reduce the stress levels for everyone.

Comments are closed.