Software development has come a long way over the last few decades. We’ve gone from extremely laborious, protracted exercises to create even basic functionality (punch cards anyone?), to the drag and drop, WYSIWYG environment of today. We’ve also gone from a very small number of enthusiast programmers to literally millions of individuals writing software worldwide (there were over 1.3 million software engineers in the US alone in 2008). And we’re all looking for ways to make building software even easier.
As the software evolution has continued, common patterns have been identified and dedicated tools have emerged to abstract these patterns and enable developers to build applications more efficiently. Over time, enterprise software platforms have gained popularity, abstracting common patterns with the promise of readymade frameworks that promote rapid development, greater agility and lower support costs.
But do enterprise software platforms always achieve this objective? Are the gains of rapid development offset by other costs – hidden costs – which don’t expose themselves at the outset? Are these platforms really the panacea they’re cracked up to be?
What’s an enterprise software platform?
Enterprise software platforms attempt to solve abstracted requirements by providing a generic platform which can be applied to solve specific business problems. The examples I’ll refer to most frequently are Microsoft SharePoint and K2 workflow but the principals discussed are equally relevant to products such as Oracle Portal or Microsoft CRM.
Let’s start by understanding what K2 is based on their description:
The K2® software platform increases business efficiency and makes work simple. Its visual, familiar tools allow people with varying backgrounds and technical skill to create applications that automate business processes and streamline operations. And when something in the business changes, modifying the applications to keep up is easy.
And a little about SharePoint from the Microsoft perspective:
Microsoft Office SharePoint Server 2007 is an integrated suite of server capabilities that can help improve organizational effectiveness by providing comprehensive content management and enterprise search, accelerating shared business processes, and facilitating information-sharing across boundaries for better business insight. Additionally, this collaboration and content management server provides IT professionals and developers with the platform and tools they need for server administration, application extensibility, and interoperability.
Both of these are very vague and fraught with business buzzwords that don’t tell you an awful lot about what the product does. I ran Bullfighter over the SharePoint description just for interest sake:
Bullfighter is a bit tongue in cheek but it has a point about obfuscation and preponderance. Let me try and distil the nature of these products into a more consumer friendly fashion:
As application platforms, these products aim to streamline development by abstracting common solution behaviours and packaging them into products which may be consumed by business applications. They both provide APIs and integrate with IDEs to be utilised at design time as well as providing server based installations which are required at runtime.
One quick clarification about SharePoint as it’s a bit of a multifaceted product; I’m referring to using it as a platform on which to write custom application code as opposed to using the native teamsite and portal collaboration features. These features are fantastic straight out of the box and are in a very different category to using SharePoint as a foundation for writing code.
What’s wrong with this?
Where the problems first arise is in customer expectation, and is it any wonder after reading the quotes from the manufacturers above? Because the positioning of the products is so generic it’s easy for customers to form opinions and set expectations with little understanding of the actual effort involved. The bottom line is that many businesses experience unexpected surprises during the development and support cycles of applications built on these platforms.
To be fair, both these products and enterprise software platforms in general can be fantastic when used in the right way. The intention of this post is to highlight areas which can be problematic in order to contribute to a more pragmatic analysis of the platforms before commitments are made.
The people problem
A serious problem with creating a dependency on these platforms is that you create a dependency on people with niche skills. This severely restricts the potential candidates you can hire either directly or indirectly through an ISV. Remember also that we’re talking about server platforms so you not only need good developers, you need good infrastructure people who understand the product.
Let me demonstrate; Stack Overflow Careers allows developers to promote their CVs online and there are currently a couple of thousand people putting themselves out there. Let’s imagine we’re recruiting for a .NET developer:
Let’s compare that to a SharePoint search:
And now K2:
So for every potential candidate you could hire to develop SharePoint applications there are eight .NET developers lining up. K2 doesn’t even feature. But is this a realistic representation of people availability? Let’s reverse the process and see how many jobs are available on seek.com.au in Sydney for the same technologies:
A little less damning than the Stack Overflow results but you’re still looking at five and a half .NET jobs available for every SharePoint one. The K2 results are a bit misleading because five of them refer to the K2 search engine. The remaining result lists K2 as “beneficial”.
The relatively small representation of SharePoint and particularly K2 poses a number of problems. Firstly, the reduced number of candidates means recruitment is more protracted as good people are harder to find. This poses a direct risk to agility in terms of being able to rapidly scale resources up and down and in turn impacts negatively on those charged with the recruitment process.
Secondly, market forces tend to financially favour those with skills which are not commonly found but are in demand. In turn, these people tend to command higher rates. The last couple of times I recruited people for a SharePoint developer role they were consistently priced around 20% higher than their .NET counterparts. Great for the candidate, not great for the employer.
Finally, it doesn’t matter whether you’re engaging individuals directly or using the services of an ISV, the same risks and costs exist and ultimately they’re passed on to the customer. The same market forces drive the cost and availability of ISVs; there are far fewer competent vendors out there developing SharePoint or K2 than there are .NET and this is reflected in their pricing.
From a cost perspective, all this begins to erode the gains made in rapid development. The fact an application may be built 20% faster on one of these platforms is quickly offset (opportunity cost of earlier delivery aside), by 20% higher resource costs.
The development environment problem
Unsurprisingly, the process of building software on these platforms is a little different to your classic development model. The surprise comes when you understand just how different the development process can be.
Let’s look at the SharePoint approach compared to traditional ASP.NET development. In the .NET approach, the developer has Visual Studio on their everyday work machine and pretty much goes from there. In the SharePoint model, the developer needs to work on an actual SharePoint server. You simply cannot code against the object model any other way.
What the SharePoint development model usually entails is running a virtualisation product such as Microsoft Virtual PC and building a sever environment complete with OS, SQL Server, SharePoint server and finally Visual Studio.
The next thing you need to consider is that running a virtual machine, particularly a server running SQL Server, is very resource intensive. Usually the virtual disk of the machine is placed on an external drive to spare the host of additional HDD activity so there is a small investment required there.
The development machine is also going to need a good allocation of RAM (at least a GB), so this will often mean increasing the physical memory of the host if it’s expected to continuing performing other tasks normally expected of a desktop computer. A machine with 3GB is pretty much an entry point but it will incur a productivity tax. Of course anything beyond much more than 3GB means moving to a 64 bit operating system which adds yet another dependency to the equation.
These are not insurmountable problems but they may come as a surprise to the unprepared. There is a time and expertise dependency in building a virtual machine, a hardware dependency on having a machine capable of running it in an efficient fashion and this potentially even creates an OS dependency because of the 64 bit issue.
A final consideration, relevant to some businesses, is that the development model has a dependency on leveraging an “unmanaged” server installation which may breach corporate desktop rules.
Sidenote: these issues and many more are articulated very well in the Stack Overflow post about What are your biggest complaints about SharePoint?
The shared farm problem
These are expensive, specialised products requiring specialised expertise so it’s only natural that organisations aim to consolidate instances into shared farms. The theory is that by decreasing the infrastructure footprint of these products the business can minimise the costs of licensing, hardware and support. The same rationale is perfectly valid for products such as IIS or SQL Server and at least on the surface, it makes sense to do the same with the enterprise software platforms.
The problem with any shared farm is cohabitation. Any application on the farm is simply a tenant and it has to play nice with all the other tenants so the farm owner creates the server equivalent of strata by-laws. The by-laws define governance designed to ensure the harmony and sustainability of the environment in the best interests of all the tenants. The extent of the governance and the freedom provided within them is largely up to the model implemented by the underlying technology.
Let’s take the example of a website hosting provider offering a typical SQL Server backend and IIS front end on a shared farm. These technologies provide a robust sandboxed model which offers the customer a large degree of both security and autonomy in that in most cases, once the resources are provisioned there is a great deal of freedom in terms of what the customer can deploy to these resources without risking the integrity of other tenants in the same environment. Customers can regularly self-deploy web applications and databases in a secure, on-demand fashion which means in terms of application agility it’s a big thumbs up for the model.
The nature of these products makes the shared farm model a little trickier. It obviously varies between products but let’s take SharePoint as a fairly typical example. One of the shortcomings of this product is that it makes code releases difficult at the best of times (I’m talking about SharePoint 2007 here), let alone when you’re also trying to secure the integrity of other applications in the same environment. Deployment of SharePoint applications packaged as a Windows Solution Package (.wsp) requires permission levels across the environment and beyond the scope of just a simple application meaning the potential ramifications of granting these rights are large. Have a glance through the DevX article about Creating and Deploying SharePoint Solution Files and you’ll get a pretty good idea of how low level a SharePoint deployment is.
The problem this leaves us with is that SharePoint apps can’t just simply be deployed by the developers into a shared farm but rather must be managed by a group that has the best interests of the broader farm in mind. Some people would argue that this model is preferable in any environment, not just SharePoint, but the reality is that many organisations simply don’t implement this degree of governance. The bottom line is that this model of deployment has a level of governance you don’t necessarily find in other technology stacks, such as your classic ASP.NET and SQL Server, and that it can have an adverse affect on agility and cost.
Sidenote: SharePoint 2010 implements Sandbox Solutions which come with the promise of greater flexibility and autonomy to the developer than what we’ve seen in previous versions. However, there are still limitations which will mean the concept of managed deployments will need to persist.
The new version problem
Products like SharePoint and K2 are undoubtedly feature rich and inevitably complex beasts under the covers. They continue to evolve and incrementally improve with each new release and with a product like SharePoint, the release cycle is only a few years. Chances are that any application you build on one of these platforms is going to need to go through an upgrade process at some time.
The problem with both these platforms is that they’re simply not backward compatible, at least not without going through conversion and testing processes requiring various degrees of manual labour. K2, for example, went from heavily promoting the use of Smart Forms as a UI layer yet now recommends standard ASP.NET webforms or InfoPath. There is a K2 BlackPearl Migration Utility available but the feedback on the effectiveness of this and the amount of manual labour required indicates it’s by no means a panacea for upgrading.
In the K2 case you then have idiosyncratic rules such as “all workflows must completely execute in the same version of the workflow in which they were started” which is going to mean some very carefully crafted migrations.
Inevitably businesses take the decision to upgrade these platforms. Nobody wants to go on supporting a single technology version for perpetuity and as new releases become available, support for previous editions wane and the argument for building new applications on the latest product becomes more compelling. Ultimately, the upgrade path needs to be pursued at some point in time and the challenges described above will be faced.
Jumping to conclusions
A risk these products all pose is that they make it very easy for decision makers to jump to conclusions. Building an app with workflow? You’ll be needing K2. Need alerts? That’ll be SharePoint then. They’re reactions based on their understanding of the product as represented by the manufacturer and often communicated at a very “manager speak” level.
These reactions are understandable, to a degree, when you remember that K2 “increases business efficiency and makes work simple” while SharePoint “provides IT professionals and developers with the platform and tools they need”. Of course by now we know it’s not that simple and there are a number of other problems to contend with.
Let me draw on a workflow example to put the problem into context. Let’s say we have a requirement to seek an expense approval based on an ASL. The input to the workflow process is a price and the business logic involves assessing this against a list of potential approvers, each with their own signatory level. There will likely be the ability to view and approve outstanding tasks and email notifications will probably be used to either call people to action or advise them of a status change. This is your ubiquitous Hello World app for workflow.
Should this be a K2 workflow? Quite frankly, no, it shouldn’t. This is programming 101 and most competent developers could put the whole thing together from scratch within a day and without experiencing any of the problems described above. Sure, it won’t provide all the functionality that K2 can but then things like reporting and escalations weren’t part of this particular requirement and are often way down the feature priority list.
The point is that the way these products are positioned makes it easy to prematurely jump to conclusions. It’s easy for this to occur when the true nature of the product is not understood. It’s also easy for this to occur once a business has invested in the project and loss aversion sets in. Neither of these are very good reasons to use an enterprise software platform.
The alternative
It’s simple; custom coding.
The current state of .NET and SQL Server is extremely feature rich, as are many comparable non-Microsoft products. Just within the current generation of the technology we’ve had numerous new features which streamline the development process in a number of ways. Just off the top of my head; LINQ, implicit typing, WCF, WF, FILESTREAM and geospatial data types and the MERGE TSQL function. I’m not saying these entirely take the place of a workflow or collaboration platform but I am saying they streamline the development process and make the implementation of most requirements significantly easier than it was even just a few years ago.
In many cases, as with the one mentioned above for an ASL based approval, custom coding is a more than adequate means of fulfilling the requirement without suffering from the problems already described as systemic of the enterprise framework approach. There are downsides though; some features may take longer to build (indeed they could become quite complex) as you don’t get the same degree of native functionality. But when you can build the entire requirement with custom code in less time than it takes just to configure the development environment for K2, the alternative approach begins to look pretty good.
Edit: Judging by some of the comments I’ve received, this section has possibly been taken out of context and I want to be clear that by no means do I advocate replacing either K2 or SharePoint with custom code in a broad-brush fashion. This example is intended to illustrate that depending on the scenario, there are times where the “roll your own” approach may be more appropriate. Not every workflow requirement needs K2 nor does every collaboration requirement need SharePoint. I’ve been directly involved in projects which have used these tools to great effect and I wouldn’t do them any differently, but I’ve also seen instances here they have been detrimental for many of the reasons mentioned above. Pragmatism and an open minded, objective approach is key; there are no silver bullets.
Proceeding with an enterprise software platform
None of the above is intended to say that these platforms are evil. There is absolutely a time and a place for them but the use case is just not as broad as many people would have you believe. In an environment with sufficient scale to justify the investment, the right expertise to support through the lifecycle and possessing business problems closely aligned to the offerings of these platforms, there may be a valid case to be made.
Let’s take a pragmatic approach to choosing the technology and remain conscious of the following:
- Understand the resource needs for building on the platform. They may be harder to find and cost more than you expected.
- Plan carefully for the development environment. Ensure the correct hardware exists and that no corporate barriers prohibit working in the recommended fashion. Also ensure greater lead time is made available to ready the environment.
- Expect a higher degree of governance if deploying to a managed environment. This may have an adverse impact on agility and come with a financial overhead.
- Acknowledge that upgrading the platform as newer versions are released may impose a more significant overhead than you’re used to.
If someone goes through the analysis process and comes out the other side with a K2 or SharePoint based solution, fantastic. They’ve done the due diligence, they understand the risks and they’ve ultimately chosen the best technology for the job.
However, if conclusions are drawn prematurely and an enterprise software platform is committed to without fully understanding the ramifications, you’re going to need a lot of patience and very deep pockets. Caveat emptor!
I’m an Australia based technologist and software developer with a general favouritism towards Microsoft gear but love my getting my hands on anything innovative that I can get excited about.
16 comments:
Great points but you are obviously not someone who is familar with K2, installing, developing etc. The workflow you cite in your article I can build in 30 minutes with escalations and multiple routes. And yes that is in SharePoint using a web part (found on K2 underground) with no code. You seem to forget that ASP.net, while a great tool still needs a great deal of hand holding for deployment, security, configuration changes from dev to test to production. I'm sure you could write the app in 1.5 days but I wouldn't show it to anyone. Rule of thumb is that if it takes you 1.5 days to write, it will take 3 times that amount to debug and harden. So realistically you around a week to write that. I'm still at 30 minutes. I loved the article - because it made me really examine the enterpise but I think the idea of custom code is crazy when considering long term cost of ownership and those developers who love to comment their code (NOT).
Thanks for the constructive feedback PK, it’s genuinely appreciated. To compare apples with apples, we need to assume the ASP.NET developer is as competent in their field as you are with K2 in which case I would not expect any hand holding. I also wouldn’t expect them to spend significant time debugging and hardening simply because the example I put forward is very basic.
What you obviously do well – and where I suspect many others go wrong – is that you understand the technology well and know how to apply it effectively. I think K2 is a great product, I just don’t think it should be the default choice for any workflow requirement without pragmatically looking at the total cost to build, deploy and support and I propose that these are often not immediately apparent.
Troy, your article is interesting. However, I find that it is very specific to your experience in what you do and also, probably relevant only in the market you work in.
You also talked about skills as if they are clearly distinguished from one another. For example, a good .NET developer will pick up SharePoint and K2 in no time. You cannot compare K2 and .NET... they are different. I would put it to you that since there are so many skilled .NET developers out there, K2 or Sharepoint should be your choice compared to more proprietary portal or workflow products. I would say that K2 and Sharepoint are so Microsoft based that it is easy to find a good resource to staff your projects.
I also agree with PK that choosing custom code over a estlablished platform is crazy.. do you build your own car or do you buy one?
In any case, your article is great that it shows how shortsightedness and lack of experience can prevent an organisation from making the right long term and strategic decision.
Cheers!
I’ve probably diluted the core message I intended to convey by harping on the custom coding alternative. I certainly don’t think this is always the best path, far from it, but I do want to encourage more pragmatism and holistic thinking which may lead in this direction. As you’ve said, it’s very specific to the environment so there is certainly no “one size fits all solution”.
The real intention of the post was to highlight areas where unexpected costs tend to arise and naturally these are driven by personal observation. I do stand by the four major problem areas as being aspects of these platforms that are not immediately apparent.
As for .NET developers and their ability to transition into products like K2 and SharePoint, I think that’s true to a degree but there is certainly a solid learning curve and the fact remains that if you need these skills in a hurry they’re simply harder to come by and you’ll likely pay more for them. Depending on the scenario this may be just fine but I believe it’s something which should be understood upfront rather than coming as a surprise later on.
@Anonymous:
"choosing custom code over a estlablished platform is crazy.. do you build your own car or do you buy one?"
ASP.NET is an established platform too. :) It's not like "custom code" means building your own web server (or car) from scratch.
I think Troy is comparing writing custom code on top of standard .NET vs. custom code on platforms like SharePoint and K2, rather than building your own web portal or wiki. In those cases having to conform to the restrictions or decisions made by your platform can actually slow you down.
This is even the case for standard .NET -- in many cases you may be better off with Rails or some other platform.
I hope no one is suggesting we build our "own SharePoint" because we have unique requirements :)
Enterprise development is never meant to be easy - if you make a buy decision based on a brochure then you better find a different role.
from what I have seen, many clients have gained tremendous amount of value by leveraging SharePoint and K2 correctly - it wasnt easy or pain free but it was the best option available and these options are getting better each year.
Any platform needs specialised skills, training and support upfront. Then the idea is you have your own people to take it to the next level as you start spinning more and more applications.
There will be times where you still need to pay to bring back the consultants for upgrades, etc. But the amount you would pay for SAP, Documentum, Livelink against SharePoint, K2, etc is very different and again these are changing each year with new offerings, improvements and competition.
Interesting post. My experiences more or less mirror your own - albeit from the software engineering perspective.
I have been involved in all manner of projects using both SharePoint and K2 where we shook our heads and wondered why we were using a battleship to row across a pond.
It's interesting that your blog post has polarised opinion so strongly.
Interesting post, build vs buy (or customise vs tweak, etc. etc.) is one of the eternal questions with software.
I have been on both sides of the fence, as a consultant advising on bespoke solutions and as an employee of a company or two essentially evangelising the "product" approach.
First principles of software apply here; what is the requirement?
If the requirement can be fulfilled "off the shelf" then great - simple support, simple procurement, somebody else to point the finger at, etc. the usual benefits of the "buy" approach.
If the requirement can't be delivered off the shelf (or without a huge amount of customisation of an off the shelf option) then bespoke solutions become viable with their unique set of benefits coming to the front - exact match of solution onto requirement, retained intellectual property, opportunity for competitive edge as your system is unique and yours, etc.
Worth noting in this context is the proliferation of a middle ground. As a SharePoint consultant, I often find myself looking at hybrids - bought platforms with customisations. Hybrids become sticky and are often the grey area for me, if I had a dollar for every time I have seen people code solutions to deliver functionality that is available in the platform, I would be a rich man.
Bottom line - understanding the requirement is critical, understanding the environment in which you may deliver the requirement is critical.
Like in so many things in life, in software understanding is probably the key!
Troy, this is a very comprehensive study exhibiting resource consideration in building and using an Enterprise Software Platform. Let me share my business related views based on years of experience in with Sharepoint, K2 and VS.Net.
To have an Enterprise Platform is an advantage to some extent because it speeds up development given the right fit of the requirements. What if there are complex business rules and external application/database connections and validations? I’d rather custom code than make alterations when using Enterprise Platforms. Given these experiences, I agree with you that using these platforms will entail fitting the right requirement to the right tool. You don’t use a knife when you cut a paper, you use scissors instead.
Migrating apps is another thing. With the limitations of K2, it is time to rethink the strategy.
For every version release, there are great additional features made available. Workflow functionality requirements are usually the same in nature and the business rules are the ones changing for each application. When more and more functionalities are added to the tool, the more complex learning curve is required for users and developers. The question is, do we need all those functionalities? One company differs from another. Platforms tend to carry on all functionalities to make generic applicability. I agree Jonathan, it’s a battleship over a pond.
-Myla
I've never seen an enterprise SharePoint solution without custom development. So while the platform is "out-of-the-box" there is still custom code with the same maintenance issues as a completely custom-coded solution. Only with a worse upgrade path. I 100% concur with Troy's article. SharePoint is only an example here, don't forget. Any platform choice should have its future cost evaluated at the strategic and tactical levels before a project design begins, and the biggest risk is ongoing access to *experienced* talent on that platform. Good on ya, Troy. You're someone who has a lot of experience in enterprise environments of global proportions so you know what you're talking about.
PART 1 (Sorry but i can only post 4096 characters - so its broken up in 5 parts)
Lets start by saying that this has for sure been one of the most interesting (albeit slightly biased) articles I have read in a while. This article has clearly been written by an individual that lives in the "time and materials" world with obvious deep levels of technical skill that can on short order deliver feature and function on par with those provided by specific targeted areas in sharepoint or K2.
I will comment on the article in an attempt to make the counter argument by playing devils advocate and will clearly demonstrate that akin to politics, ANY point of view can be strongly motivated through articulating opinions and gathering carefully researched and chosen facts to support those opinions.
Let me also say that I am in no means trying to diminish rationale behind the article or the skill of the .net developer who wrote it. This article piqued my interest in an enterprise world where we make long terms business decisions to bet the farm on enterprise class software vendors and platforms that provide measurable and tangible return on our investment. Does this article and argument carry merit? Absolutely! but only under certain circumstances, and those needs to be qualified and put into a "real enterprise" environment perspective.
So, I now take the devils advocate stand and shall attempt to counter the defenses arguments under each topic:
PART 2
What's an enterprise software platform??
Agreed, this is mostly marketing fluff, but these ubiquitous "we solve world hunger" words are carefully crafted for a very good reason; the person at the top of the food chain in large enterprises with buying power is NOT the slightly technical IT director with a small departmental budget to implement a quick one-shot "departmental expense approval" workflow requirement. They are targeting the VP level decision maker with 3 million dollars worth of budget that is pressed to efficiently streamline his business and reduce cost. He talks to analysts like Forrester and Gardner that live and breath marketing fluff. To these decision makers "application platforms that streamline development and abstract common behaviors and package products and provide API's and IDE's thats used at design time as well as providing server based installations required at runtime" are the black-magic things James Cameron must have used to make his hit movie Avatar.
These 3 million dollar budget owners only care about a solution that will "Increase business efficiency" and solutions "that can help improve organizational effectiveness".. They go to Gardner and ask; "So.. Who do we talk to in order to make our business effective and improve our organizational effectiveness".. At this point the hundreds and thousands of extortion money these vendors paid Gardner to meticulously analyze their platforms will kick in and Gardner will turn around and say "Well, K2 and Microsoft of course!"
Whats wrong with this??
Unfortunately thats the way you engage with real enterprise customers. the sale starts at the top where (to use a good friend's analogy) "The rubber hits the sky" and world hunger wants to be solved. But the reality and unfortunate truth is, there will always be snags regardless what technology you choose.
PART 3
The People problem??
Like I said before, numbers and metrics can be researched and skewed to fit anyone's "political point of view". To make a single counter argument. look at Free software like linux and the rest of the stacks on top of it.. I can throw out millions of dollars of software licenses from IBM, Microsoft, K2, EMC, etc and replace it with Free Software.. but it will cost me double in resources, maintenance and support. Point being; any point of view has metrics to support it.
The development environment problem??
This is not isolated to share point or any other piece of technology. Yes, with Sharepoint 2007 there is a specific set of requirements (which goes away in 2010)but any sharepoint developer and implementation specialist should know about these caveats up front and plan for it accordingly. There are no hidden surprises here at all.. The only hidden surprises are when building custom solutions the deployment scripts and packing of applications and deployment strategies needs to be coded and built and tested and documented and skill-transferred by the actual developer of that custom artifact.
The real problem for the enterprise comes in the shape of a problem that is not highlighted in this article at all; Developers do not have access and will never have access directly to production systems. there is NO option for a developer to directly "simply deploy" a sharepoint app.
In real enterprise environments, you have a team responsible for each discipline in the business.. i.e a sharepoint farm admin and a K2 administrator that is authorized and that understand how to do effectively deploy a solution (that was packaged with a single click) into a no-touch secured and hardened real enterprise environment.
The argument of agility versus cost does hold water, but, this article is targeting real enterprise deployments and in my experience, real enterprise environments are typically globally distributed with very strict policies enforced on production deployments, making it complex, therefore inherently expensive.
PART 4
Shared Farm Problem??
I dont see the relevance of multi tenant hosted applications to an enterprise class business solution?
fact - both Sharepoint and K2 scales out and up through Load balancing and additional resources in terms of CPU and Memory without ANY consideration on the solution developers part.
IF you were to code custom app with C# whilst being true multi-core aware and cluster / load balanced aware with built in redundancy, the cost and complexity of your custom application has shot through the roof.
The new version problem??
This is a very poor argument and the "idiosyncratic rule" of all workflows must complete on the same version is untrue.
I can make an equally poor counter argument: I would love to see a developer "upgrade" the old VB6 and SQL6 custom app that was built years ago by a person thats no longer with the company and did zero documentation and now seamlessly migrate over to the new enterprise Java based application running on Oracle (thats hopefully documented and the new developer will be around after 5 years)
An equal amount of effort will be envolved in the migration versions of solutions, either custom coded or a custom Sharepoint or K2 solution. Keep in mind, neither of these platforms are off-the-shelf retail applications that has a finite and known set of parameters like for example a standalone SQL or Exchange server. Both these are platforms that allow rapid development of very complex business solutions.
Migrations between major versions of these types of platforms have well respected software vendors with skilled consultants behind them to ensure the success and continued support of such migration efforts. Will it be as easy as a single click? No.. Did the business solution appear out of thin air when the platforms was installed? No.. So I dont think there is an expectation that a single click migration between major versions of these types of enterprise platforms is realistic. And to be clear, there is a big distinctions between upgrading between versions of a release (which is a simple installer based upgrade) and Migration between major releases thats based on a Migration utility and backed by technical resources and support. The same can be argued for a standalone product upgrade like upgrading from Exchange 4.0 directly to Exchange 2010
PART 5
Jumping to conclusions:
Throughout this article, there has in my mind been some jumping to a number of conclusions based on biased opinions. And again, here is the counter argument:
The simple workflow example is great and agreed it can be quickly built by a skilled developer to provide these functions to an end user. but thats where the argument stops and a biased jump of conclusion has occurred
This article is attempting to highlight the "hidden costs of building enterprise class platforms" and so to be entirely fair, the example should be a real enterprise level problem that gets solved with these platforms in question.
This example is not a large complex enterprise level business process that was automated through platforms like K2 and Share point. it was a simple 2 day exercise by a skilled C# coder to solve a very basic sub-departmental level problem.
We will spend hours and hours documenting the effort involved if we have to really delve into some real world "Enterprise" problems thats typically being solved by these platforms in the context of "increasing business efficiency" and "help improve organizational effectiveness" to at the end of the day streamline the business and reduce costs.
The Alternative??
Agreed, if you work an a small agile department or environment and need to get something done, do it yourself with a piece of custom code that you documented and you know how to package, deploy, support, maintain and train people on (for the next 3-7 years)
For real world enterprise level business problems that needs to be solved with the backing of vendors with skilled resources and support infrastructures with the promise of continued innovation, go talk to Gardner and Forrester and ask them how you should solve your 3 million dollar problem with 2 million dollars of budget and get measurable return on that investment within 1-3 years. Their answer will probably not be pointing to the 4 person internal IT department staff of C# developers.
Proceeding with an enterprise software platform:
I hope that this drove the point that indeed enterprise platforms are not evil and that ANY argument can be motivated with the right amount of conviction and data to back it up.
In short:
If you are running a small company and dont have big enterprise problems to solve, please dont go and spend three times your annual revenue on a enterprise platform and then try and find problems to solve in order to justify the cost. Use the lowest cost tool with the resources on hand that gets the job done.
If you are a multi million (and billion) enterprise with real business problems and you are up for streamlining your business and reducing operational cost. Which in todays economic climate, everyone should be looking for ways to shorten business process cycles (streamlining your business) and in doing so save a lot of money (cut cost).. Go talk to the analysts and get a real opinions based on real researched data and fact.
Thanks everyone for providing a good range of comments from a number of different angles. I find it interesting that although I intended to talk generically about these platforms the majority of comments have been about K2 experiences even though I referenced SharePoint more frequently. Perhaps there is just more passion in the K2 community!
Bias is natural as we all comment based on our experiences and our opinions are naturally shaped by these. If I can draw a common theme it is that these platforms need to be approached with an enterprise-grade mindset and proper planning and due diligence is absolutely essential. As the last anonymous poster commented, these products are intended to address large scale business problems and this is where they really shine.
If my views cause debate which results in further discussion and valuable insights – both good and bad – from a broad cross-section of people, in my book that’s a good result. For the passionate K2 supporters, ensuring your customers achieve a positive experience with the product is obviously paramount to you and I really appreciate the constructive feedback and offers of support. It has been very well received!
Let me finish by reiterating my sentiments at the end of the original post:
“If someone goes through the analysis process and comes out the other side with a K2 or SharePoint based solution, fantastic. They’ve done the due diligence, they understand the risks and they’ve ultimately chosen the best technology for the job.”
Post a Comment