What applications to create on a new project

Hi, 

Yes, you can create the above mentioned 2 application, one for CDTs /Database and Groups and another one for creating all other artifacts. 

If you are using the new Appian platform then I will suggest creating a new application called Common Application which will consist of all the generic rules and constants. 

Thanks

My recommendation would be to find a relatively simple paper process that you think you could optimize using Appian.

For instance, one bank client I was working for had a process whereby a lending specialist would fill out an excel sheet containing the details of a loan product a prospective customer might be interested in.  A member of another role at the bank would receive a paper copy of that excel and type the values into another system by hand.  Eliminating that swivel-chair by doing it automatically would be a huge cost savings to the bank and not be terribly complicated to build in Appian.

What would you need?  You'd need a SAIL version of the form; either a way to print out the data, a webservice or the like to send it directly to the other system, or both; a process model to run it all; and possibly you might want to store these in a database for auditing.  If you are going the database route, you'd need at least one CDT to match the table you're going to be writing to.

You might have a paper process, or a legacy system, for requesting time off.  That would need a SAIL form, a process model, and tasks assigned to various roles.  You'd have to manage groups, permissions, and would probably want to add swimlanes to your process models.  You might want to persist requests in the database, and possibly generate reports.

The project I'm working on now, the client hated Remedy, so a couple of developers were tasked with building an Incident Reporting solution in Appian for tracking tech support tickets.  That only took about a month for 2 developers to fully replace Remedy with a custom built Appian solution.

Ideally your first project would follow one central flow and encompass one and only one overarching process / product.  It only requests time off.  It only makes initial loan requests (no other kinds of requests).  It only carries tech support tickets through their lifecycle; it's not a code repository, it's not a diff tool, it's not an IDE, it's not a project planning tool, it's not a collaboration bulletin board, it's not a knowledge sharing platform, it's not a SCRUM meeting organizer, it's not a release planner, at least not yet; it's ONLY a support ticket tool.

But whatever process it does or product it creates, it should be big enough that it utilizes essentially every kind of Appian object there is.  You would almost be remiss if it didn't have process models, subprocesses, datastores, cdts, records, groups, actions, related actions, loads of expression rules, maybe document generation, and maybe a report or two.

And don't make it just to make it.  Make something that will get used and be much better than what it replaces.  Get your buy in.  Give the business ROI early, and let them see early that they made a good choice picking Appian.  That will secure you to tackle a much bigger project that does lots of things next.

A very wise trainer drilled into my brain that an application [in this context] is just "a collection of objects".
The primary purpose of an application is to move objects from one environment to another.

In previous versions of Appian, that product's dependency checking on import wasn't as good as it is today.  You needed a DS application to prevent dependency errors when importing new applications.  Product improvements over the years include smarter imports that recognize new data stores / entities first, so as to prevent dependency errors.

All that is to say that, for starters, one application is acceptable.

Over time, as your application grows, you might like to create new application objects for different reasons.  For example, after a major release, you might want to create an <<APP>> R2 application to help you more easily keep track of the objects that were added or changed after the first release.  You can do this again for R3.  

Some teams like to make a new application every day to further facilitate ultra-fine-grained tracking of changes. 
There are pros and cons to this approach that I'm not going to get into now.

Do what works for you and your organization.  

Certainly a solid approach might be to construct one singular functionality to it's logical conclusion, this is your first "app".  You next "app" could be more functionality added to the same code base; make it do more.  Many of the speakers at Appian World last spoke about their first functionality being the start of a suite of functionalities that all fall under the same umbrella, and as Mr. Shankin is keen to point out logically belong in the same container called an Application.

I think it's important that for first iteration purposes we try to limit scope while using the full set of tools.  You'll want to keep feature creep off the initial project until you get a win, if you can.  Then, after victory, you can indeed add features.  If you do so in a more structured way, you have something akin to a regular product release cycle and less like a neverending battle against changing requirements.

Thanks Robert Shankin and all for your answers. 

Your answers were useful and helped me to decide to start with one simple application