My team has been writing a dashboard application using Node.js, Twitter Boostrap, Mongo DB, and Mule for an ESB.
Recently an executive asked us to change our approach to a Portal/Portlet container like Liferay.
Some of us on the team have experience with Liferay, and we have pretty negative feelings about it. Dealing with things like full-page refreshes, portlet lifecycles, style and theming issues, and limited DBMS coverage are at the top of our list of complaints.
We see where our executive team is coming from. They have decided that they want to make the dashboard extensible and easy or easier to plug into for other groups.
Is there a solution out there which can balance the modern web expectations of users with the enterprise needs of IT professionals and executives concerned with building and extensible application with something like Liferay? Pluggable widgets are important here.
Node would obviously be our preference with something like Grails as a close second.
Thanks,
This question may not exactly be a good fit for StackOverflow's format, but I can offer some thoughts still.
If you want to stick your current platform, you need to figure exactly what features your executives want to get out of moving to a new platform. Are those features something you can build into your current platform? How much effort will that take compared to rewriting everything else? How effort will it take to learn a new skillset across your whole team? I'm sure your team can learn the new skills effectively but that still takes effort and there will be growing pains as your teams learns. If you can show to your executives that you can get the same features for a similar or less effort and that you can still have similar total cost of ownership, you can make a case to stay on your current platform.
Also I think you are underestimating what a Portlet container can do. I work mostly with WebSphere Portal so maybe thats why I think most of the pain points you mentioned really aren't that difficult to manage for me. Just because your container needs a particular DBMS to manage itself does not mean you can't use a separate DB for your custom data needs. JSR-286 introduced serveResource as a way to make AJAX easier to implement in portlets. In WebSphere Portal (don't know about Liferay), changing out the whole page content without a page reload might the most difficult on your list I'll admit though.
Modern doesn't have to mean bleeding-edge tech. And the large software products can still perform if you know how to use them right, just like any other tool.
Related
I'd like to ask is it smart enough to ship a web service/product without creating any CMS?
I mean in order to ship it faster and get some feedback from users it will be smart from my point of view to ship it w/out CMS and build it as you go but Im afraid from technical point of view - would it create any big problem that would be painful to solve?
Tnx.
Well, it depends on what you expect from the website. Should it be only a one-time web presentation, I think it might be okay to ship it without a CMS. I would also consider it fine if you didn't want to run a database for whatever reason (as most of the CMSs use database).
If the product is meant to be more complicated, it's definitely easier to start with CMS than to hack it in the product later.
However, if you decided for the latter way, you might find CouchCMS interesting. Though I haven't tested it myself, it looks very promising and easy to inject into an existing website.
Is there a way of offering the flexibility of Excel/Access development that end users love while instilling centralised IT management so data and logic is secure, backed up, version controlled etc. The common options are to re-write in C#/ASP.Net/Java/Python/Your Choice, but that takes away control from the users. Is there a better way, and what do you do at your site?
There is a universal issue of users creating fantastically useful Excel/Access mini-apps that the IT department would like to bring under control. Users love the flexibility that Excel affords, especially on the fly changes, graphing and data import/export. In Access we have brilliant QBE. The downside is that after a short while there are legions of out of control spreadsheets/mdbs which are mission critical, with lots poorly understood business logic, and brittle code, they're a pain to support especially as staff move on.
This puts the IT dept in an awkward spot, they'd like to support these apps, but don't know enough about them. This is made more difficult as they are typically insecure with zero documentation.
Having been of both sides of the fence I would go after the root cause of the problem. Why do uses make their own little apps? Because it is too hard/expensive/time consuming/never turns out right when they go through the “proper” channels.
The other thing is they tend to know the business very well so whilst their coding might not be very good their knowledge of what needs doing is very good.
So what can we do to combat this problem? I personally think their should be a small team of people within IT whose job (or one of their jobs) is to develop these small applications. They should work very closely with the end users and not be locked in the ivory tower of IT.
In my current role I’m on the non-IT side of the fence, I have a few quite major applications that needed to be developed so I asked for an install of visual studio and some space on an SQL server. I had my request denied. So I just asked for SQL server space, again request denied (each request taking about a week to go through) So in the end I’m “stuck” in access.
Now these are very nice access apps with version control, comments in the (shock!) and all the other nice things but at the end of the day I was trying to do things the “right” way and ended up being forced down the access route. So when my apps try to get scaled up and I’m quoting a long time for a rewrite who is to blame?
Have you considered looking at SharePoint for department-level applications? Many professional developers will balk at the idea of using Sharepoint for "application development," but it truthfully can be a great way for "power users" to start putting their data and tools in a managed framework.
With SharePoint, you can manage the overall structure of the site and then set up users with elevated permissions within their respective departments. There are some great 3rd-party tools to help with keeping an eye on what's going on in your SharePoint site.
SharePoint is not a silver bullet by any means, but it is great for many multi-user applicatinos that need to keep up with a list of data.
(The following is not really related to my above answer, but your question really hit home and I thought I'd share my similar experiences and insights.)
Our company will be going through a similar process in the near future. I'm on the "end user" side of things and can sympathize with a lot of what Kevin Ross said. Sometimes Access and Excel are simply the best tools available for me to get the job done.
Here's an example: I was asked several years ago to come up with a system for creating Purchase Orders to a vendor in China for product for which there is a 3 month lead time. Our ERP software had a few features for procurement, but nothing that even came close to the complexity of the situation we were facing. Years later, after going through several iterations of the application in Excel (VLOOKUP was a lifesaver), Access ("So that is why people using relational databases. Awesome!), and back in Excel ("let's not make this so complicated"), I still find that these Micorosft Office apps are the best tools to get the job done.
What's the cost to not use these tools to get the job done?
Contract work to our ERP vendor to add a special feature for this ordering process: are you kidding me? We'd likely pay tens of thousands of dollars for an unflexible monolithic application with horrendous user experience...and we would still end up back in Excel.
Buy third party software designed for this exact process: I've seen an on-site demo of software that does exactly what I want for our procurement process. It starts at $100,000. There are probably other tools that we can get for a few thousand dollars, but at that price point, I've already emulated most of their features in my own application.
Try to finish the job "by hand." : Ha! I'm a programmer at heart, which means I'm lazy. If it takes a solid week of sitting at a desk to work up a purchase order (it actually did take this long), you can bet I'm going to work up a solution so that it only takes me a few hours (and now it does). Perhaps the guy after me will go back to doing most of it by hand, but I'll use the tools in my toolbox to save myself time and stress.
It's so hard to find the perfect application to allow for maximum creativity on the user end but still allow IT to "manage" it. Once you think you've found a solution for one thing, you realize it doesn't do something else. Can I write I printable report in this solution like I used to do in Access? Can I write complicated Excel formulas that tie multiple data sources together from different sheets ("You want me to learn what? No, I've never heard of a "SQuirreL query" before. VLOOKUP is just fine thankyouvermuch)? Can I e-mail the results to the people in my department? Can it automatically pull data from our back-end database like I do in Excel and Access? Can I write my own code, VBA or otherwise, to make my job easier? The list goes on.
In the end, the best advice I can give to any IT manager in your situation is to respect the other workers at your company. Let them know their work is important (even if it's only useful to them and the guy at the next desk over). Let them know you are not trying to make their job harder. Don't assume they are morons for creating mission-critical applications in office productivity software; they are just trying to get the job done with the tools at hand and are usually quite capable and intelligent people. Invite them to explore different solutions with you instead of just removing the tools they currently have in their toolbox and then replacing them with ones they don't know how to use.
At the end of the day, if you have users who are smart enough to shoot themselves in the foot by creating complicated apps in Excel and Access, they are probably smart enough to learn to use the appropriate tools to accomplish the same tasks. Invest the time and energy to involve them in the process and you will have a solution that works for everyone at the end.
You could try a hybrid approach: Allow your users to use Excel/Access to home-brew their own, specialized tools, but take the mission-critical stuff and put it under IT control. There are a few strategies that could help you with this:
Make sure that your IT department is firm on VBA. Not the "yeah-everybody-can-write-a-few-lines-of-basic" type of knowledge, but in-depth training, just like you would if it were a less simple programming language. Although "real programmers" will tell you otherwise, it is possible to write large, stable applications in VBA.
If you currently have the data in Access databases, move away from that and migrate it to an SQL Server. This allows you to do centralized backup and management, while still giving your power users the flexibility to "link" these SQL Server tables to their Access frontend.
Commonly used business logic should be under control of your IT department. This can be done either with VBA, by creating an Access library that is linked by your users, or in any of the .net languages, using COM interop. The latter sounds more complicated than it is, and it will increase the satisfaction of your IT department, since developing in .net is just much more rewarding than VBA (version control possible, etc.).
I would second one of Kevin Ross's main points:
I personally think their should be a
small team of people within IT whose
job (or one of their jobs) is to
develop these small applications. They
should work very closely with the end
users and not be locked in the ivory
tower of IT.
I think any IT department that has a lot of users using Access/Excel should have at least one properly trained and experienced specialist in developing apps on those platforms. That person would be the go-between to make sure that:
IT's priorities and policies get properly implemented in the home-grown apps.
the end users get expert help in converting their home-grown efforts into something more stable and well-designed.
I would second Tony's point that whoever works with the end users in revising these apps to meet IT standards should work side-by-side with the users. The Access/Excel specialist should be an advocate for the end users, but also for the IT policies that have to be followed.
I also think that an IT department could have a specialist or two on staff, but should also have a full-time professional Access and/or Excel developer as a consultant, since the on-staff people could probably handle day-to-day issues and management of the apps, while the professional consultant could be called in for planning and architecture and for the implementation of more complex feature sets.
But all of that would depend on the size of the organization and the number of apps involved. I don't know that it would be desirable to have someone on salary who is nothing but an Access/Excel specialist, precisely because of the problem you get with all salaried employees compared to consultants -- the employees don't see as wide a variety of situations as an active consultant with the same specialization is likely to see and thus the consultant is going to have broader experience.
Of course, I recognize that many companies do not like to outsource anything, or not something that important. I think that's unwise, but then again, I'm the person that gets hired by the people who decide to do it!
If it's mission critical, and it's in Access or Excel, is built poorly, and no one understands it, it is probably time to rebuild it properly.
When the 'users' are in control it usual means one particular person is in control of the architecture, design, coding and documentation... except they normally omit the documentation step. Source control and bug reporting, the touchstone of software development, is usually absent. Few instances of code reuse, due to the nature of Office apps (code modules usually embedded into documents) and VBA (little OOP, most VBA coders don't use Implements, etc). All this means that the resulting applications are not subject to get proper scrutiny and quality can suffer, meaning there are likely to be maintenace issues, escpecially when that one user leaves. I know because I used to be that person ;)
So in order to satisfy the IT department, the proper process needs to be applied. That one 'power' user can continue to own the design and coding but will get peer review, perhaps the serivces of a technical author and a dedicated tester, be required to use source control, perhaps consider integrating with enterprise systems, etc.
There is no getting around the use of Excel/Access. It's what's available, and still very powerful and flexible. The best thing to do is offer some guidelines as to how files should look and be set up. If everyone is using similar standards then the files will live longer and more productive lives, beyond the creator's tenure at the company.
You've got some excellent answers regarding dealing with the folks and the business side of things. So my response will be more technical.
If you are going to redesign the app have the developers work in the same offices as the users. Given the users updates every day or two. If the users have any minor suggestions give those to the users within a day or two. Ultra Frequent Application Deployment
Give the power users an Access MDB/ACCDB linked to the tables with a bunch of starter queries. Let them create the queries they need to export the data to Excel for their own purposes and distribution to clients.
My company is in need of a task management system to handle scenarios as simple as "Purchase a computer for X" to "Relocate a person to another country". The simple scenarios are a single tasks handled by a single person, whereas bigger tasks can be broken down into multiple sub tasks delegated to multiple people during the workflow. Additionally the clients and vendors need their own views into the process.
We are evaluating different solutions from a custom application built on Workflow Foundation to SharePoint to BPM products like Metastorm and BPM.Net.
Here's my current understanding of these solutions:
Workflow Foundation - Low level workflow designer and/or library with no host environment. It seems we would have to reinvent some wheels if we went this route such as fault tolerance and document management. Some of the answers on stack also cause concerns such as the lack of versioning and a complete overhaul for VS10/.NET 4.0
SharePoint - Built for document management and collaboration but trying to create advanced workflows and tasking on top of that seems like a hack. Plus all workflows have to be tied to either documents or lists. I cant envision how a list (or list of lists) can address this issue.
BPM products - Mature workflow engine at a seemingly high price. BPM.Net is the only solution for which I could find some level of technical detail but im still not sure how different developing against this product would be from developing against Workflow Foundation.
Are there any workflow engines dedicated to solving all the workflow pains that can be easily deployed with their own hosting environment and initiated through a webservice?
Are there any other options I am missing?
Thanks in advance.
****Edit**
To answer the questions below the workflow needs are pretty light. Basic routing of tasks to approvers and subcontractors.
Whats driving us too look deeper than PM software is the nature of the business not the need for advanced workflow. We are basically in the business of procuring goods and services through subcontractors for our clients which can also include full employee relocation. The interface of the package should reflect this by being customer branded as well as intuitive for this line of business.
Basically if im moving my family to the other side of the world Im not sure i'd want to interface with Jira or Sharepoint or any other PM software to facilitate this.
If you are on Microsoft stack I would definitely recommend SharePoint for this scenario. As it seems to be very simple you can go with Windows SharePoint Services edition because it is free and it has everything you need.
You are right when you say that ShartePoint workflow are bit limited. IMHO the best way to overcome that limitation is to purchase Nintex workflow to create your workflows. It is cost effective solution that can help you design workflows you need.
You can find workflow samples inside the product (as workflow templates) and on the web site.
Nothing you mentioned has much to do with workflow. You're just doing project management. If that's the case, a simple bug tracker (like FogBugz! ;) would work - but if you're going to show it externally, it may not be the most professional presentation.
The closest off the shelf solution I can think of would be Project Server - though, depending on the number of projects and project managers, the desktop Project with a sync to a webserver for client views may be enough.
If that's overkill - because your projects don't require a lot of resource scheduling, Gantt charts, or other PM artifacts - you can take something like Trac and replace "bug" with "task". ;) (Seriously though, that'd probably get you 90% of the way there.....)
Have you looked at RT? I believe it can handle all your requirements, including that it's designed to let customers interact with the system by email, rather than having to log into the website. If you've emailed IT support desks then you've probably interacted with it without knowing... You can also completely customise the web interface and allow customer access.
Can't vouch for the quality as I haven't used it, but I did watch an online-demo video of Intalio, which has BPM and workflow capabilities.
We use Basecamp to control this sort of "task management" stuff. I'm not sure if it fits your needs totally, as it's a little light on the document management side, but it has a web service (REST) API, customer / vendor facing components, and basic interaction / chat capabilities.
The best part about it is that the API is simple enough where you can offload a lot of the "management" for it to admin support personnel, like assistants and interns, by providing custom scripts. If you've got people who aren't programmers using it you'll probably have better luck with it than even something like Trac or FogBugz.
I have/am going through a similar process. We wanted a lightweight workflow for internal use by our sales team. Most of the third party apps we looked at ,K2 and Skelta BPM.Net in particular, looked way over the top for what we needed. I'm now 2 months into working with Windows Workflow Foundation 3.0 and I have to say it isn't the most pleasant coding experience I've had.
If your workflows will truely be simple then it is pretty easy to build a workflow and hook it up to some web pages for the UI. But if you need to be able to change it on the fly, or do versioning (ie the user says we want another step added, then its a whole lot of hacking to get it to work - and it only works if you limit your workflow to being really simple), then you are in for a fair bit of work. And forget about it if you use an Oracle database.
The next version of windows workflow will have it's own runtime environment, code name dublin, with will provide a WCF interface into the workflows.
If your timeframe allows you could use that.
For information on Dublin and the next version of WF see:
http://www.microsoft.com/net/dublin.aspx
My vote is for FogBugz. Unless I am missing something in your requirements, why would you want to reinvent the wheel by using a code based workflow solution where you have to code up the flows yourself when you can use a perfectly good project dependency solution like FB or even MS Project Server - which lets you create nice dependencies for resources and people.
Check FileNet
FileNet is expensive but makes a good job with content and process management, but I guess is not what you are looking for.
We use Captaris Workflow, it is pretty good but it may be expensive for your needs.
In my organisation, we have some very inefficient processes around managing requirements, tracking what was actually delivered on what versions, etc, do subsequent releases break previous functionality, etc - its currently all managed manually. The requirements are spread over several documents and issue trackers, and the implementation details is in code in subversion, Jira, TestLink. I'm trying to put together a system that consolidates the requirements info, so that it is sourced from a single, authoritative source, is accessible via standard interfaces - web services, browsers, etc, and can be automatically validated against. The actual domain knowledge is not that complicated but is highly proprietary and non-standard (i.e., not just customers with addresses, emails, etc), and is relational: customers have certain functionalities, features switched on/off, specific datasources hooked up - all on specific versions. So modelling this should be straightforward.
Can anyone advise the best approach for this - I a certain that I can develop a system from scratch that matches exactly the requirements, in say ruby on rails, grails, or some RAD framework. But I'm having difficulty getting management buy-in, they would feel safer with an off the shelf solution.
Can anyone recommend such a system? Or am I better off building it from scratch, as I feel I am? I'm afraid a bought system would take just as long to deploy, and would not meet our requirements.
Thanks for any advice.
I believe that you are describing two different problems. The first is getting everyone to standardize and the second is selecting a good tool for requirements management. I wouldn't worry so much about the tool as I would the process and the people. Having the best tool in the world won't help if your various project managers don't want to share.
So, my suggestion is to start simple. Grab Redmine or Trac and take on the challenge of getting everyone to standardize. Once you have everyone in the right mindset then you can improve the tools you use for storage.
{disclaimer - mentioning my employer's product}
The brief experiments I made with a commercial tool RequisitePro seemed pretty good me. Allowed one to annotate existing Word docs and create a real-time linked database of the identified requisistes then perform lots of analysis and tracking of them.
Sometimes when I see a commercial product I think "Oh, well nice glossy bits but the fundamentals I could knock up in Perl in a weekend." That's not the case with this stuff. I would certainly look at commercial products in this space and exeperiment with a couple (ReqPro has a free trial, I guess the competition will too) before spending time on my own development.
Thanks a mill for the reply. I will take a look at RequisitePro, at least I'll be following the "Nobody ever got fired for buying IBM" strategy ;) youre right, and I kinda knew it, in these situations, buy is better. It is tempting when I can visualise throwing it together quickly, but theres other tradeoffs and risks with that approach.
Thanks,
Justin
While Requisite Pro enforces a standard and that can certainly help you in your task, I'd certainly second Mark on trying to standardize the input by agreement with personnel and using a more flexible tool like Trac, Redmine (which both have incredibly fast deploy and setup times, especially if you host them from a VM) or even a custom one if you can get the management to endorse your project.
What open source toolkit does fatwire compare to and are there some particular advantages to fatwire?
How hard is fatwire to export out of and move to a free alternative?
How stable is it as a platform to write java extensions on?
From a development persepective, FatWire can be unfriendly. Having worked on a number of sites using this application it can easy bloat, and become difficult to maintain.
From a user perspective there has been alot of effort in the UI and this has led to a highly functional tool.
From a client perspective all clients bar 1 (a large news agency) were happy with the end result. FatWire can slow when using complex logic to generate menus or breadcumbs for example or when you have a large amount of content. This is the main reason the one client was unhappy. The FatWire site regularily struggled under the load. It sometimes seen as a solution to all web needs.
As such FatWire succeeds in serving Static Content & Semi Dynamic content, but can flounder when forced to do fully dynamic sites (from my experience).
From the original press release:
FatWire Software announced the rollout
of FirstSite, which is a set of tools
and best practices that helps
companies using FatWire Content Server
get their first Web site or
application running quickly while
providing a foundation for future
expansion. FirstSite includes a
collection of standard templates and
site components that are common to
most sites, combined with
documentation, training, a rich
developer community, and best
practices methodology. FatWire and its
solution partners are using FirstSite
as the basis for developing
content-centric applications for
specific vertical markets. With only
minor, cosmetic alterations,
developers can use the code in
FirstSite to implement a first site,
while simultaneously learning how to
utilize Content Server's capabilities,
such as dynamic content delivery,
personalization, caching, and product
catalogs.
Firstsite is not a product, unless this has changed since 2004 (unfortunately I cannot look, since their developer site is down). Fatwire's Content Server does not compare to any Open Source CMS that I know. It's scope goes much further. I will answer your questions one by one:
Advantages - There are many (or nobody would buy it, and it is not cheap)
On the delivery side: scalability, fine-grained cache control, stateless servlet architecture, ....
On the back office side: virtually no limit to asset types, dynamic content attributes, find-grained security and access control, ...
On the development side: Intelligently architected API with good coding productivity, tag library, ...
Openness
You cannot easily expect to migrate content between any two CMS products, open source or not. While there are ways to extract contant from the database in XML and other forms, using product tools, or simply at the database level, I don't think that this can be an argument for or against using a particular CMS. Ever tried to migrate from Drupal to Joomla?
Stable
I worked on several Fatwire implementations from 2000 to 2004 (back then it was OpenMarket Content Server, then Divine Content Server). It was stable enough for the Washington Post, the New York Times, and the S&P sites, and I would expect stability not to be an issue today.
Fatwire is really unique concept from developer point of view. It builds everything on a very abstract, extremely flexible clever asset modeling framework which is stored in relational database.
Application logic is based on "templates" which actually are pieces of JSP code. This JSP code is not like conventional Java, but tags instead. It takes very long from a developer to learn these tags and Fatwire asset api. Expect even months before skilled develpers start to be productive.
Almost nothing useable samples ships along the product. There is advertized "FirstSite" but it is way too simple for the purpose this product is used normally (huge complex sites). So pretty much everything has to be built from scratch.
Cache control is advertized to be one powerful feature. Yes it is, but we had extremely long learning curve and it never worked exactly like one assumed.
Wysiwyg editing has been missed from this product even it is advertized. At least during 2009 it had serious conceptual problems which practically prevented using it in live environments. But it was cool feature for demos and marketing of course. Today it might be fixed.
As a summary and if I were a customer with limited budget, I'd select any open source alternative instead. Mostly because development costs with Fatwire are high due the uniqueness of the product, lack of good documentation and extremely long learing curve. Of course the product price tag is also thing to consider.
And to answer to questions: you have to start from scratch if you move from Fatwire 6.0 to any open source alternative. And it is stable to build Java extensions on.
Fatwire stores content in relation database and file system. Depending on what type of content (structured/unstructured), Fatwire can be evaluated.