This is another post in our discussion on DVCS and git (see our git category in the right column for more). Distributed version control (DVCS) makes it easy to share changes as every change has a guid or unique id. With DVCS git, you can get the best of both worlds: simple merging and centralized releases. We will continue a Wednesday post on aspects of git and git resources into May. Atlassian provides a git tool with their Stash offering. In this post I want to go over the key steps in migrating to Stash.
Before You Begin:
Make sure the following steps have been completed.
Staging Environment – Set up a staging Stash environment to perform a test run of your import first, for review and validation before doing the production run. Note, this is best practice for ANY major service efforts with Atlassian systems. You can use an evaluation license for this test.
Atlassian Stash, git, SVN installed – Install Atlassian Stash on staging server, as well as git and SVN. (SVN install is required for the import processing.)
Mail server – Configure SMTP mail server settings on Stash serverbefore you begin the import process. At the completion of the import, you will receive an email notification of success or failure (which can take a while depending on the size of your import).
SVN Permissions – You will need permissions authorization to your SVN repositories that will be imported, or the ability to import the SVN repositories “anonymously”. The importer supports both scenarios.
About Stash Logging – Stash process logging is logged to logback.xml in stash-home. Importer logging is logged to stash-home/logs.
1. Review the “Before you begin” checklist and “Getting Started” steps.
2. Access the importer user interface, as follows:
Select the Source Code Import option in the Repositories menu, or,
Click Import… button from the Projects screen
3. In the UI, define your SCM, and URL for the SCM Repository Source.
If you require SVN authentication, select “Use Authentication”. You will be prompted for SVN username and password.
If no authentication is required, do not select this option. The import will access SVN anonymously.
If the SVN server URL is https, no problem. The certificate will be detected, and this is supported.
4. Define your Stash target, as follows:
Select “Existing” or “Create New”.
Select/define project (depending on existing or new).
Define repository name
5. Click [Fetch SVN authors…] button to continue.
6. In the Source Code Import Details screen, your set import configurations are shown. Stash users are mapped to SVN authors, but you can override these mappings here. Check/adjust all of your SVN authors as desired, then click [Import into Stash] button to continue.
7. The Source Code Import Commenced screen is displayed. When import process has completed, an email with results will be sent to the logged in Stash user.
If an error occurs during the process, the import is halted and you will be emailed the results.
At anytime during the import, you may check progress in the Importer logs, located here: stash-home/logs.
Depending on the size of your import, the full process can take some time, so please be patient.
8. Repeat this process on your production server
9. Congratulations!and we’d love it if you let us know about your success!
If you have any questions on DVCS and how best to work with git and Stash contact us at: firstname.lastname@example.org. At AppFusions we have also developed a Source Code Importer for Stash, Atlassian’s git offering. This importer significantly decreases the challenge of migrating SVN to git.
IDC concludes that the “increasing sophistication of use cases demonstrates that the market for enterprise social software is maturing quickly. Organizations are looking to engage internal users and customers in an ongoing conversation, inside and outside the firewall. As usage increases in breadth and depth, activity streams, discussion forums, blogs, and wikis are becoming assumed functionality of enterprise social software to facilitate collaboration in real time and in context.” I would certainly agree with this assessment.
Application integration is increasingly becoming a success factor. IDC notes that “Customers are demanding broader and more specific collaboration scenarios that tie together internal and external constituents, deliver sophisticated insight into user behavior on the network, and extend seamlessly across mobile form factors.” These seamless extensions and the connection of internal and external constituents requires comprehensive integration that is designed to address business objectives.
Their key success criteria include: the ability to extend activity streams, blogs, and wikis to a broad range of stakeholders. The optimization of the mobile experience, comprehensive analytics that can “perform behavioral and predictive analysis on data generated by the network,” a scalable platform that can extend to customers, and partners, as well as handle different roles, company sizes and industries, and “prepackaged integrations with collaboration tools and major enterprise application vendors delivered via the cloud.”
IDC notes that such social tools as activity streams and blogs are becoming required functionality within the enterprise. As social tools mature beyond initial marketing applications, use cases have grown into such areas as customer experience, sales enablement, digital commerce, socialytics, innovation management, and enterprise social networks.
The latter use case provides a means to find relevant information and people through connecting people, data, and systems in an overarching system. Collaborative workspaces are the outcome and the foundation for the connected enterprise.
Enterprise adoption of the new enterprise social software is on the rise. There has been as 40% year-over-year market growth. In this current survey 67% of organizations have implemented a corporate-sponsored enterprise social software solutions. While there are standalone solutions, many vendors have moved to more open and connected offerings through the use of APIs. This allows social software to be embedded within work processes, a topic I have covered before (for example, see Putting Social Media to Work and Giving Social Media a Good Job)
IDC concludes that “enterprise social software will eventually become the backbone of the ESN for a number of reasons.” This is being fueled by the recognition that connecting employees, customers, and partners is key to success. As McKinsey found, “higher operating margins (again, self-reported) than competitors correlated with a different set of factors: the ability to make decisions lower in the corporate hierarchy and a willingness to allow the formation of working teams comprising both in-house employees and individuals outside the organization.” Collaborative technologies create more agile organizations and these companies achieve higher profits.
In 2012 IDC expects to see enterprise applications and other collaborative applications being upgraded to include social functionality or becoming integrated with enterprise social software solutions in a complementary fashion.
It is an exciting time and we are pleased to be part of it thorough application integrations.
It’s been a great last week, as AppFusions has been closing down on many preparations for the imminent IBM Connect 2013 conference in Orlando, Florida from Jan 27 – Jan 31. We are sponsoring an exhibitors booth at the event, and can’t wait – it’s going to be a great event.
Further, last Wednesday we received a mail notifying us that we’d made the cut for a stage demo at the 2nd annual “App Throwdown” event – an open demo/contest for OpenSocial application integrations into IBM platforms.
Here’s a video of last years, where we were sitting in the audience. Now, maybe we’re app integration geeks or something, not sure — but anyways, for us this event got us into quite a bit of an excited tizzy! It screamed “APPFUSIONS!”
After the session we all mutually agreed: “WE need to be on that stage next year!”
And now we will be! Yay!
In the last week, our development team has continued working hard at putting in many last minute polishes to show off IBM and Atlassian software, together, for the following integrations:
IBM Sametime in Atlassian JIRA, Confluence, Stash, Fisheye, and Bamboo
Atlassian JIRA, Confluence, and Stash in IBM Connections
Wherever a user’s name shows up in the interfaces, presence indicators tell you whether your colleague is available to chat. If green (available), right click on the presence indicator and start a chat on the fly.
Bring in other colleagues for group chat, or if your IBM Sametime subscription allows for video conferences, go ahead — launch into those too — all from right inside your Atlassian tools!
As for the IBM Connections integrations, of course these are a bit different – but also super convenient to bring together platforms, and more, workflows.
Feature highlights include:
From IBM Connections, launch the sharebox and log a JIRA issue straight-away from IBM Connections.
Atlassian JIRA, Confluence, Stash (and Bamboo, coming) activity is pushed continually in real-time into IBM Connections, with:
live contextual / actionable links back to your Atlassian systems – or,
you can launch a JIRA embedded experience for commenting or status dispositioning, from IBM Connections.
Atlassian Confluence is integrated into IBM Connections as the “wiki of choice”. (From the Apps menu, find Atlassian Confluence wiki at your fingertips.)
Finally, if you are one of those mobile types (aren’t we all?!) — we’ve got you covered there too. Directly within IBM Connections’ mobile application, find native JIRA and Confluence application nodes!
As great as all this is – it’s only the beginning!
AppFusions will be continuing to feature develop these integrations throughout 2013.
We can’t wait to see how they evolve, with the help and great ideas of IBM and Atlassian customers who in our experience, like AppFusions, simply want to “bring it together!”
RedMonk recently posted on Centralized vs Decentralized Version Control: 2010 vs 2012. They mentioned that the inquiries regarding decentralized or distributed version control (DVCS) technologies, such as git, has spiked. RedMonk went on to add that some organizations are considering migrations to such technologies, while others have committed to the move in general, but require data to justify their decisions internally.
In the RedMonk post, they looked at the question of DVCS usage via Ohloh over the past two years. The two most obvious changes from 2010 to 2012 are the decline in CVCS traction (centralized) and the growth of git (decentralized). git’s share, in particular, almost tripled in two years, while CVCS declined by better than 50%.
They also presented at chart of the leading repositories. Each decentralized repository, including git, demonstrated growth while the two centralized systems, CVS and Subversion, declined. Second, git substantially outperformed both Bazaar and Mercurial from a growth perspective.
It seems that developers are voting for decentralized git repositories with their feet, or perhaps their keyboard/mouse.
RedMonk showed further data that indicates there is still room for more growth for git. If you look at the absolute numbers, rather than growth, centralized repositories are still in the lead. Their data show that while nearly a third of all projects are now employing DVCS, versus 14% two years ago, almost 70% of projects remain in centralized version control (CVCS).
RedMonk concludes the git is the clear winner over the past few years.
In line with this trend, Atlassian Stash – Atlassian’s behind the firewall git repository manager – is gaining good traction in the market, as can be expected. BitBucket, their SaaS DVCS offering (supporting both git and Mercurial) is also growing fast – both being yet more alignment to this growing trend.
I spoke with Jens Schumacher, Atlassian’s Group Product Manager for developer tools. These tools include: Bamboo, Crucible, Fisheye, and Stash. Bamboo provides continuous integration and release management. Crucible supports code review and Fisheye allows you to search out source code artifacts of various source code management flavors and browse commits, files, revisions, or related people. It also integrates seamlessly with JIRA.
Enter Stash! Stash incorporates the latest and greatest technologies in DVCS source code management and Git, allowing you to create and manage repositories, set up fine-grained permissions, and collaborate on code in a secure, fast and enterprise-grade manner.
Jens continued, providing me more background on the development of Stash.
Stash is the latest in Atlassian’s developer tools suite and was released in the Spring of 2012. Atlassian’s existing developer tools are already quite popular in development houses, but still the developers wanted more. They wanted to be able to host code in their own repository behind the firewall.
More – engineers are always pushing the envelope: they wanted Git support, a massively popular and growing DVCS approach used in code development and management these days.
To cleanly meet this need in both a tool and extensibility, Atlassian decided to build Stash from scratch including a ground up extensible API approach, rather than on top of their existing tools.
Stash incorporates code review into the development workflow so the new code gets properly reviewed before it is merged with the existing source code.
To facilitate development, Stash allows developers to set up branches, where code changes can be made in isolation and reviewed before being integrated with the mainline. This separation makes development of new features less complex.
You can easily have new code reviewed while incorporating automated testing tools as well. Stash facilitates the merging of reviewed code into the core source code. This concept of a separate workflow for development is popular with open source efforts and Atlassian has now taken a leading industry position with the Stash offering, enabling this capability inside the firewall.
Integration efforts with Stash are already supported in a number of ways.
Per Jens, 80% of the Fortune 500, as well as many many smaller firms, use Atlassian JIRA for issue tracking.Stash is fully integrated with JIRA so you can link code in Stash to a JIRA ticket and track the progress of changes.
Stash also natively integrates with enterprise user directory systems, such as Active Directory or LDAP, to make deployment easier within the enterprise.In addition, again, Stash was built with an extensive REST API to make information within Stash easily integrate-able with other tools.
Jens gave me a simple use case. Their customers often want to migrate content from one repository to another or from the cloud to within the firewall. Stash can automate aspects of this common process to simplify the effort.
In the future, Stash will be enhanced with more branch permission capabilities to better ensure that all code gets reviewed before it is merged into the core source code. They are also working hard on scalability requirements to better serve their many large customers. Currently, Stash supports up to 500 user licenses. Finally, they are working on adding enhanced collaboration capabilities for code review.
Jens noted that Atlassian has a massive ecosystem. This is helpful as there already are a number of add-ons for Stash. For example, there is a badge add-on to acknowledge developers’ efforts and skills. Another is a chart add-on to provide statistics. AppFusions built a Stash commenting add-on for Atlassian’s annual CodeGeist competition. Also, add-ons are available to help with different workflows that organizations have in place.
On top of all that, Atlassian’s very popular SourceTree DVCS client further removes DVCS source code tool complexity, and is used to support and guide the process of adding new workflows with proper controls within branching efforts, among other.
Customer response has been very positive since the release of Stash earlier this year. The timing was right for the release, as developers were ready for it.
Jens’ team is now providing new releases every 7 – 9 weeks, with many of the new capabilities coming from customer input.
New needs are always arising in enterprise software development efforts, and many organizations and third party developers want to tackle these needs. Stash provides enhanced support for these efforts.
Just received a googlegroup mail that is too good to not share, from Don Brown, Atlassian’s engineer extraordinaire, and in his current incarnation, Atlassian’s “remote app”, eh hem, PLUGINS 3 Framework Design Architect!
He and his team (including Bob, Sam, Yon) finally solved the riddle – the riddle of:
providing a single application development AND deployment framework for both on-premise and OnDemand instantiations of Atlassian’s platforms (i.e., Confluence, JIRA, etc.).
It was a riddle that rattled long and hard in recent months, and really since the release of Atlassian OnDemand (and months before … over a year ago!).
The answer: Introducing Atlassian Plugins 3 Framework!
While I could summarize, sometimes emails are left best in the perfect state that they came in as.
This is one of them.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Don Brown Sent: Monday, August 20, 2012 3:21 PM To: email@example.com; firstname.lastname@example.org Subject: Remote Apps is now Plugins 3
Over the next few months, the Remote Apps project will be transforming into Plugins 3, which is intended to be a complete replacement for Plugins 2. The scope of Plugins 3 has expanded past just remotely hosted applications, and now brings its permissions and (now optional) sandboxing capabilities to in-process plugins as well. We expect to deliver the first developer preview of this technology at AtlasCamp 2012 in September .
The backstory here is after our Summit 2012 presentation, we’ve been having a bunch of internal discussions as well as discussions with partners and existing plugin vendors about the capabilities and future of Remote Apps, and two limitations quickly stood out:
Remote Apps isn’t on-premise friendly
The sandboxing was too restrictive for many (most?) existing plugins
The first limitation was really the showstopper – if we encourage plugin vendors to write Remote Apps that can only work for OnDemand, 85% of our current customer base, the on-premise installations, won’t benefit, and worse, it could mean fewer and fewer plugins as developers won’t want to maintain two code bases. The technical problem with Remote Apps and on-premise is that, since all the code is running on a remote server, it requires the on-premise Atlassian product to be addressable from that remote server, which almost always means the on-premise instance must be open to the Internet. The only ways to get around this – some sort of reverse HTTP firewall-poking agent or locally installed Remote Apps – are not where we want to go.
The second problem of sandboxing is because Remote Apps was an all-or-nothing proposition. Your app had to exist fully in the UI sandboxes we had in place (IFrames or strict HTML sanitization). What we wanted instead was to expand the permission system to include permissions that would allow any plugin, in-process or remote, to be written, and therefore, ensure 100% of existing version 2 plugins could migrate.
The solution we decided upon is Plugins 3. With Plugins 3, you can write a single binary (jar file) and deploy that plugin locally (in-process as you do now) or remotely in a standalone container running on a platform like Heroku. Within the plugin descriptor itself, there will be information on where the plugin is hosted remotely if that installation method is chosen. Therefore, the developer experience is like this:
Write a version 3 plugin
Deploy to Heroku (or where ever) to support OnDemand instances using the provided standalone container
Register in the Marketplace as supporting remote and local installations
When an OnDemand administrator clicks ‘Install’, they will have the plugin installed as a remote descriptor pointing at your remotely hosted instance. When an on-premise administrator clicks ‘Install’, the plugin jar will download and run in-process like before. In both cases, the same plugin jar that was registered in the Marketplace is used.
Foundational to Plugins 3 is the concept of permissions, where a plugin is required to declare what APIs, code execution privileges, or sandbox breaking capabilities it needs. In addition to the existing Remote Apps permissions, Plugins 3 includes additional ones like ‘execute_java’, ‘use_private_apis’, and ‘generate_any_html’. This provides Atlassian the ability to define which permissions are available to side-loaded plugins in OnDemand, which need curation in the Marketplace, and which are only available for on-premise installations.
In all cases, the OnDemand or on-premise administrator will have to view and explicitly approve the permissions before the installation can take place. This also means Plugins 3 will be able to support every current version 2 plugin with the quick migration step of adding permission declarations to the plugin descriptor.
However, if the migrated plugin is to be able to be executed by the container, significant effort, if not a complete rewrite, will likely be necessary.
In a nutshell, here is what has changed:
New permissions element in plugin-info in atlassian-plugin.xml
New plugin module descriptors for each Remote App extension point
Ability to use atlassian-plugin.xml instead of a Remote App descriptor, though the Remote App descriptor format is still supported
New container for running a version 3 Plugin outside the product
Set of services that are implemented in container and local versions
In the next few days, we will be merging this work, currently in the ‘p3’ branch, into master. I will also soon be publishing a Plugins 3 Tech Spec with a lot more detail than I’ve given here. I’m excited about this new direction as it will bring the benefits of Remote Apps to all plugins for both OnDemand and on-premise. Our goals are to make plugins secure, easy to write, and OnDemand-friendly, and the future looks bright.
It leverages the firm’s most expensive investment, its people, to build revenue. Application integration is a foundation for this collaboration and Jive has certainly recognized this need in their product strategy.
It is built to enable several use cases. One is building internal social intranets, supporting collaboration across the enterprise to break down silos through such features as activity streams and social groups to achieve the value described above.
Another is enabling external support groups. In this case companies set up external customer communities to address questions from other customers. These efforts have shown to both build customer engagement and loyalty and reduce support costs.
Mark said that Jive recognized the need to have integration with a firm’s legacy systems, their custom systems, and their other third party systems to put their own capabilities where work gets done. I could not agree more.
Jive did their research and found that their customers spent 34% less time searching for information and experts, had 28% fewer support calls, a 33% increase in customer satisfaction, and a 34% increase in brand awareness after they implemented Jive.
The key to getting this value was opening up their platform so collaboration could more easily occur across applications. To facilitate meaningful collaboration they provide such capabilities as an activity stream called “What Matters”.
In this case Jive allowed employees to move away from the fire hose of content provided by many activity streams to focus the content through several means.
Jive’s What Matters stream intelligently provides only the relevant information to the user based on the information that is visible to them and the relationships they have in the system. For example, if you are a member of a group, then you will see all the activity for that group.
In addition, Jive’s activity stream delivers targeted information a user’s social “inbox”. The social inbox is managed by the user and they can choose what information is delivered there.
The user can set up custom activity streams that combine information that is relevant to their specific context. For example, to quickly and easily follow all the activity of a company’s executive staff, a user could simple setup a custom stream and select the relevant e-staff members. In addition, Jive created a recommendation engine that pushes content to you based on your behavior in the system.
Application Integration Strategy
Jive based its application integration strategy on OpenSocial.
They made a significant move to adopt this opne, community driven standard and Mark is now the President of the OpenSocial Foundation. OpenSocial defines a Web based component model for the delivery is cloud applications along with a set of social APIs that allow an application to be easily embedded into a platform and take advantage of its social elements, e.g. the connections between people and their activities.
It gives a clear programming model and an easy way to use APIs. This allows legacy applications to be integrated with today’s leading edge social collaboration platforms. You can give legacy systems a “social life”. This allows the creation of connections where employees might not have previously used an application.
For example, AppFusions built a JIRA in Jive application that enables this integration on a seamless basis. (Here’s the video.) There are many situations where one employee might not have access to application where much needed content resides. For example, while the IT department might use JIRA for issue tracking, a sales person who does have JIRA might want access to the JIRA status on a customer issue. Now with the JIRA in Jive connector, they can bring JIRA into a Jive conversation and ask about how the issue is progressing.
I asked Mark about their next steps in integration. He showed me an interesting demo where you can have embedded experience form multiple applications in an activity stream. He started a discussion in Jive. Then he referenced an INXPO Social TV event to in the content.
Next, he brought in additional content from Wikipedia, and CrunchBase. Activity around discussions naturally flow into the stream in Jive, and because of this other users were able to gain visibility into this exchange of information.
The technology that these interactions are built with is using OpenSocial’s embedded experiences. Jive calls our realization of that “!App Experiences”.
I asked Mark more about that. He told me Jive’s !App Experiences is an exciting way to embed applications directly into Jive content, e.g. a discussion. Because the application is embedded with the content, the application is available wherever the content is.
Mark then logged in as another person and could access all the content right within the activity stream without having to go to the other applications or have them installed. This provides for a very rich collaborative environment. It allows you to contribute to a conversation where you are working.
Jive’s activity stream (“What Matters”) intelligently determined that this person should see the content that Mark created. When they looked at that activity stream entry, the artifacts that the application embedded in content were clearly indicated as special links.
When the user clicked on an embedded !App Experience, the application opened and the user was able to have a rich interaction right from where they were in Jive (again, in this case, the activity stream).
Finally, you can also create action tasks for follow up to the original post in yet another tool, such as Goshido. Now multiple applications are linked around a work activity.Jive is the glue that brings all these application together.
It was very impressive and an excellent demonstration of how the connected enterprise should operate.
Matt said that with the release of JIRA 5.0 they have launched a multi-pronged effort to expand their support for the increasing number of enterprises that are adopting Altassian products on a larger scale. First, there is now a dedicated 24/7 telephone support team to address enterprise issues.
This is a great move that I wish more software providers offered. Also, included with your Enterprise Atlassian JIRA license, there is free administrator training that focuses on how to handle large instances. An Enterprise-customer-only online-support community is also now in place with quarterly input and support meetings. In addition, there are developers on the Atlassian product teams that focus only on ”Enterprise” issues. They are addressing issues like scalability (for both users and content), as well as performance.
While this increased enterprise effort started with JIRA, plans are in place to also address Enterprise-level issues with Confluence. One move to make Confluence more accessible for enterprise users was the rebuilding of the editor that was launched with Confluence 4.0, making it easier for the non-technical user. There continues to be focused ongoing improvements in this area. I can attest to this as I have been using Confluence a lot recently and I find it quite intuitive.
See screen and explanations below.
Bill pointed out that Confluence has always been aimed at the enterprise and the business user since it first started in 2004. That was one of its distinguishing features versus the open source wikis available at the time.
This focus has driven usage by an ever-increasing number of business users in large organizations. Logically, they have now added new layers of support and product development to accommodate them.
We next talked about adoption. Matt said that Atlassian focuses on tools for teams that build products. Its initial clients were in IT and product development groups. But product development goes beyond IT to such areas as marketing and support, which of course subsequently expose Confluence to larger numbers of users.
Atlassian continues to add features to increase adoption by these newer audiences. The complete rebuilding of the editor is one example. Bill added that they have continued to make the design intuitive and also provide more on-boarding support. Among much others, Atlassian are working on a new solution for providing templates out-of-the-box, including business process ones to help new users see value faster.
I asked about Atlassian’s expanding customer base, as their list is quite impressive. They said from the beginning the business model has been bottoms-up adoption. They have made the product and the price points attractive to teams so that senior executive budget approvals are not required. Then the product spreads through the organizations as people find that it is easy to use and it helps them get their jobs done better.
Atlassian has focused on what their users tell them, rather than what analysts prescribe. This has been very successful. For example, when someone moves to a new role or a new job, they take Confluence with them.
I think this bottoms-up approach to sales is even more relevant today in the world of BYOD and self-provisioning, as users no longer rely completely on IT to furnish apps – users are taking matters into their own hands.
One important move for Atlassian in this direction was the release of their software as a service (SaaS) offering – an on-demand version of Confluence. Users can more easily self-provision and you can also start with a 30-day free trial of the on-demand version.
This combination of On-Demand and instant trials has significantly increased the number of trials to more than 50 a day and has lead to many new users. It has also increased the sales of the on-premise version, or still opt that direction.
We next covered their enterprise integration strategy. I think this is key since without integration across other apps that customers use daily, more silos are created and proper workflow does not occur. Matt said that they have built a platform in all their products that accepts add-on integrations and opening the door to third-party developers, like AppFusions among others, to build integrated solutions.
The recent released of the Atlassian Marketplace at the end of May 2012 was a major move in this direction. Third-party developers can place their add-ons in the marketplace and Atlassian handles all the business issues, including payments. This is a win for all parties as customers only have to deal with one source at the procurement level: Atlassian vs. third-party developer “shops” spread across the globe. Some third-party developers report that their evaluations have more than tripled.
Bill pointed out that the integration requirements are not limited to legacy Enterprise apps. They are getting demand for integration add-ons for other cloud-based tools like Google Docs, Box and Dropbox, all of which are being met in the Marketplace.
He added that plug-ins go well-beyond simple connectivity integration issues, including also allowing for increased functionality. And these cloud-tools are not just used by consumers or SMBs these days. More and more large customers are starting to also adopt these tools, for both cost advantages and IT convenience.
I like the flexibility of their business model and the creation of the marketplace where everyone wins.
All of the moves to support the enterprise that we discussed make a lot of sense and I can see why sales have grown significantly. I look forward to seeing what happens next.
Before we describe the place of AppFusions in the new world of Enterprise 2.0, it is useful to go back to look at the Enterprise 1.0 world which is still current for many.
Enterprise 1.0 – “A Single System For All”
In the Enterprise 1.0 world, large ERP systems claiming to be a “single system for all” integrated many (if not all) departments and functions across a company into a single computer system. They attempted to serve all the different department needs, running the business, successfully in some places, and not so successfully in others. These systems bridged the needs of products, customers, employees, and suppliers. (Below image from this excellent slideshare by Samuel Driessen.)
For many years, this cross-functional single-uber-system was thought to be the ultimate glue to solve all problems: the silver bullet solution to propel corporations fast forward in their business success.
However, despite best intentions, these lofty goals were hard ones to meet in a single system, given many mixed audiences and purposes between departments.
Cross-functionally, departments wanted to control (customize) their workflow.
While ERP systems were configurable out of the box – to a point – in most cases, they required costly customization SLAs to develop or configure the workflow exactly how a department wanted it.
Data integrations to other systems were extremely expensive ($50K – $200K+), given the reliance on niche technical knowledge in closed systems.
All integrations were like “black magic”, requiring ongoing support and vendor reliance without a natural support path.
Integrations where time-consuming and costs could be as much five times the software fees.
Over time, specialty purpose-driven or “rogue” systems crept into organizations (large or small), as department heads rebelled against the rigid IT uber-system, and shopped for their own systems to meet their department needs.
For the companies that succeeded in their ERP deployments, they paid dearly in implementation costs, yet also they got bigger and faster with these large system infrastructures. For a while, they enjoyed a competitive edge in their locked-down systems.
no, you cannot change the process or system (without an enormous amount of additional churn, cost, pain – to which we have no more money to expend).
Employees were forced to adopt the new inflexible systems, a change that often felt like steps back even from their slower, yet functional desktop processes.
Compounded with normal human resistance to change, the new systems were not always warmly received. People had to conform to rigid systems, rather than having flexible systems built around how people worked best.
The enormous level of cross-functional process coordination upfront, as well as the long term support for these systems, was often more crippling than helping. The systems had the potential to control corporate data in a better/faster way than previous manual ways, but it held employees hostage in so many other ways, and caused new problems organizationally.
Politics and internal fights evolved to ever high levels as employees felt duped when the new systems didn’t really do everything that they thought it would, and no customizations were allowed. If a department absolutely required customizations, they’d have to take the heavy cost hit in their departmental budget (not ITs), let alone the time-hit to implement (e.g., another 6 months often, assuming it got done before some other organizational crisis hit).
Companies would endure the growth of excessive politics, mistrust, and infighting causing systematic morale issues and lower productivity. Employee dissatisfaction grew at a higher than normal rate, as well as distrust for management who forced the new monster system on them in the first place (even if it was justified at the time given where technology was at).
In short – it was a vicious and often ugly cycle, especially for large corporations enduring these growing pains.
Outside the Enterprise 1.0 World, the Beginnings of Enterprise 2.0 Technology Moved Forward
Meanwhile, the open source movement had gained “officialness” in 1998 thanks to Netscape (Mozilla), and during the 2000s, the open source trend and collaborative engineering mindset grew more popular with the growth of Linux, further proving the value of both iterative agile engineering, open APIs, rapid development methodologies, and at the communications level – transparent collaboration.
Concurrently, the Internet was taking off well beyond the Silicon Valley, thanks to Yahoo! (1995), Google (1998) going big/global (as well as Microsoft with Internet Explorer). For the Enterprise, early pioneers Jive Software, SocialText, and Atlassian Software were founded in 2001 and 2002, respectively – three corps that would become pioneers in the Enterprise collaboration tools space in the years to come.
Atlassian also would become a leader in many of the open source stirred trends, namely agile development, ALM, engineering tools, and issue tracking, while boldly treading on common industries lead by big heavyweights like IBM, HP, and Microsoft, among others.
Overall – the timing of these new Enterprise collaboration businesses couldn’t have been better, overlapping with early social sites like MySpace (2003), Delicious (2003), Facebook (2004), Digg (2005), Twitter (2006), FriendFeed (2007), and a strong new-way-to-business Millenials culture pushing into industry with all their might.
By late 2009, open collaboration and social networking was no longer an idle idea.
It was a fast moving trend and way of the future, that had proven the beginnings of enormous business value for getting things done faster in the Enterprise. Concrete data began to emerge on the quantified value of these new approaches (see The Business Value of Application Connectors).
However, to be successful in the new world, people-centered Enterprise 2.0 apps need to connect with the old world transactional-centered Enterprise 1.0 systems. They needed to connect to each other to avoid establishing even more silos within organizations.
While AppFusions does not really believe in the legacy gigantic one-size-fits-all system ideal, at the same time we know that in most cases, these systems are largely not going away.
The new social systems of engagement still need to connect to the old world transaction systems to get work done.
AppFusions Bridges the Gap with Enterprise 2.0 Content Management Integration Connectors
We believe that business information and process management should be handled by a collection of systems that make up a whole. To make this happen, connectivity is the key driver. It is the glue that makes real work happen. It brings the benefits of social systems to work processes.
Modular system architectures in the Enterprise – from the same vendor or many vendors – provide greater flexibility, while also allowing organizations to pick and choose the best-of-breed systems for their purposes.
There are reasons for purpose-built systems, and a collection of many we feel is stronger than a single rigid system, especially if you can connect the strengths (data and workflows) of the different systems with common use case connectors vs. getting on an endless customization path.
Our integration connectors (current and future) bring together workflows, data files, and information between Enterprise systems for your collective purpose-built Enterprise 2.0 corporate solution of many systems. They allow companies to quickly and cost-effectuvely create the needed connectivity without going through the old-world pain of massive, costly, and time consuming integration efforts.
These connectors provide the means to close the gap between old and new, enabling the promise and opportunity within the capabilities of the new people-centered, social systems.
This blog will become the vehicle to tell this story and provide use cases demonstrating the essential nature of connectors.