I’ve spent a lot of time with customers over the last year working with the internal people who are delivering apps to business users. You are out there busily building apps, setting standards, listening, supporting and connecting things. Your technical skills range from beginning builders to workplace wizards. Along the way it has become clear that core fundamentals of CorasWorks have gotten lost or are at least lumpy. I am not talking about technical items, but, about how to think about what you are doing when delivering collaborative work management apps using CorasWorks. I guess with the time, new folks coming in and churn it makes sense. In this article, I’ll go over my list of Top 10 fundamentals of CorasWorks that every app builder and every application service delivery manager should know.
You can templatize an App and Reuse it for another Purpose/Group
A key value proposition of CorasWorks is the reusability. Yet, a surprising number of people don’t even know that you can templatize and re-use an existing SharePoint site. So, if you build a CorasWorks app, why not re-use/re-purpose it for another use. Better yet, how about maintaining a central catalog of cleaned, re-usable application templates, and, giving it visibility across business groups.
Context vs. Content
I often hear business users say that the UI of a CorasWorks PS delivered app is simpler to use, easier to understand and much better than native SharePoint. The reason is context vs. content. An average native SharePoint user is used to working in a team site. By design SharePoint is a content driven experience – really collaboration by proximity. You go to some place (a site) and hit a page to access content. CorasWorks changes this. Effectively, what you do with CorasWorks is overlay a business context. When our Professional Services does the work we use our in-house standardized application templates that strip away all of the ancillary content baggage like announcements and quick links and provide business users with an experience that is relevant to the business context. This seems much “easier” to business users. I recommend that you take a look at our PS standard and do the same.
Three Main Tiers of CorasWorks App Value
When using CorasWorks, you can add value in three main tiers. Always triage your work into one these tiers as follows:
- Self-service – this is where you expose native SharePoint and CorasWorks capabilities to a broad group of users that use them to enhance their team collaboration sites.
- Standardized solution types – CorasWorks has defined, trains on, and supports about 15 types of standardized solutions for collaborative work management. The idea is for your organization to understand these, buy or build your first one, catalog them, and reuse, reuse, reuse.
- Custom solutions – These are solutions that are so unique that you need to do requirements and then build them out. The box for doing this with CorasWorks is very, very big, particularly when leveraging the Advanced Framework of v11 (see next item).
NOTE: Most people are binary; either self-service or custom. What is really lacking is the middle tier – this is probably the area of greatest opportunity to add value to your organization.
CorasWorks v11 and our Advanced Framework
The Advanced what??? The current shipping version of CorasWorks is v11.2. This is the 11th major release of our core platform since 2003. With CorasWorks all of the software (.dll’s) are in this platform product. Your solutions are created on top by configuration. v11 includes an Advanced Framework. This is a multi-tier app framework that allows you to build very custom extensions or new apps without doing custom compiled code. You can even go as far as to build a custom database app with a separate SQL server database and a CorasWorks front-end surfaced in SharePoint – again without custom compiled code. This means that your IT Governance model can be centrally managed, but, the business groups can get lots of value. The box of what you can do with CorasWorks is probably a lot bigger than you think.
Basic Apps are Built Up – Like Layering
When you use our basic framework/components we call that a basic app. A standard, single-site CorasWorks basic app is built up. It is like an assembly line. The standard steps are:
- Create a new site using a standard base solution template
- Add navigation
- Modify the data – lists and libraries, custom “workplace” fields, and data relationships
- Add basic displays (usually grids for apps)
- Add forms (action forms for new items and in process action forms)
- Add user task automation actions
- Add email notification actions, activations and workflow
- Add reporting
- Add Advanced Framework extensions (after business user feedback, see last point)
CorasWorks Actions Control What Users Can Do
CorasWorks comes with its Actions Framework. Using a wizard you can create actions for users to perform. This is your control point. It allows you to separate the user from the data (If you think about it with native SharePoint you are pretty much giving users direct access to the data). So with your apps, think actions for users. They need not know what magic the action does behind the scenes or what gets kicked off (emails, workflow, other actions, etc.).
CorasWorks Cuts Across Structural Barriers of SharePoint
Native SharePoint has a number of structural “barriers” that constrain your canvas for designing and building apps. CorasWorks separates the user context from the content meaning that people can basically do anything from anywhere. We make all of SharePoint your design canvas. The main barriers we cut across are data types, lists, sites, site collections, web applications, and, even farms. The impact is that for advanced designers they think in terms of the actual user experience wherever and in whatever context vs. the app user interface.
Apps: Single Sites vs. Distributed Systems
Most people are site bound. They think of SharePoint site by site – because they have learned to live within the barriers. In reality, SharePoint is a distributed system or even more correctly a “system of systems”. Sometimes you will build a single site app, like a Help Desk. Other times you are really designing and building systems – a collection of sites. An example is a Portfolio of project sites where you might have a PMO, a couple of Portfolio Management sites, and a mere 50 or 100 project sites spread across departments working in different site collections. The key is to design at the system level first, thinking about the user role and experience, with the local sites coming next. Back to the Help Desk and that single site. Where do the users enter in their Help Desk requests? Where do they see the status and activity? Can they first search a knowledge base or access a self-service community? Should it really be designed as just a single Help Desk site for 10 help desk engineers or is it really a system to help users be more productive with a user population of say 3,000?
Think Collaborative Application Design Patterns
Most users think that an IT Help Desk, a Chemical Materials Storage Request system for a Pharmaceutical, and, an IDIQ HR Staffing app are very different applications. To a CorasWorks builder they are basically the same with a bit of work to customize the “language” of the app. In effect, they are what we would call a “Request” collaborative application design pattern. In this world of collaborative work management apps you begin to see that most apps fit into common, re-usable patterns. This is what drives the repeatability of our Standardized Solution Types mentioned above. Thus, a catalog of 10 standard base app templates representing each of the solution types can serve your needs to create 100’s of business function specific applications.
Think about the Work-Stream(s)
We are very focused on the app. In practice, this allows us to focus and meet a need. However, in reality often work in one activity kicks off work in the next. Or, in order to get the work done of one app you need to tap into another set of teams/apps/processes. When you step back and see how these activities tie together, you are thinking about what we call the work-stream. For instance, in the big picture, an Idea Management app, would hand off to a Project Approval App, that hands off to a Development Project app that feeds your Change Management app. The project approval app may have a process to request a capital expenditure (from finance) or a market study (from marketing). Each of these apps can live on their own and usually have completely different users and contexts and make up multiple work-streams. But, they connect. They are loosely coupled. And, you can have them all inter-operating within a CorasWorks-SharePoint environment.