Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
Replies
1 reply
Subscribers
9 subscribers
Views
845 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
Administration
Hi All, We're expanding our development group, and I was hoping t
cgoldsberry
over 10 years ago
Hi All,
We're expanding our development group, and I was hoping to get some best practices/administration guidance from the Appian community on how to manage distributed development. Up until now, development has typically been performed by one person at a time for a specific application/improvement. I'm trying to create an organizational model that will promote rapid development and hopefully avoid stepping on each other's toes if we're working in the same Application?
Some specific questions:
- How is your Appian development group structured?
- How do you manage application development? Is it 'X person is responsible for Y model', or do people work collaboratively on the same model?
- How do you manage iterative development? If an application is already deployed, how are improvements managed?
Thanks for any advice you can provide!
Chris...
OriginalPostID-103637
OriginalPostID-103637
Discussion posts and replies are publicly visible
Parents
0
aayusha
Certified Senior Developer
over 10 years ago
Every thing depends on architecture of the application.
It should so loosely coupled that different persons can work upon different components. This link (
forum.appian.com/.../BPM_Application_Delivery_-_Actualize)
will give you an idea to how to decide components so that multiple users can work upon same projects.
#1. So, before actual development, find out the common functionalities in different parts of the process and which users going to utilize and divide the process in number of components.
As you decides you sub processes and main process. The sub process are modeled by different users and the developer of main process directs the sub process node to a dummy PM (having only start and end event with no pv!s). And when the dev of sub process completes only the mapping of variables remains.
To avoid confusion of variables, a common pattern is decided before hand.
Many other activities can be done in parallel like process, dashboard/Records, Reports.
#2. person X assumes that person Y will be providing that data at some point of time when all the mapping as stated in #1 is done.
#3. While in iterative development, the required enhancement should not disturb the functionality of currently running instances. Eg: user should not change the number of parameters of existing rules (which are already in production). This may result that PM is of older version which takes let say 3 input for rule and the rule is modified and take only 2 parameters, then the current running instances will give error.
Hope this helps.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
aayusha
Certified Senior Developer
over 10 years ago
Every thing depends on architecture of the application.
It should so loosely coupled that different persons can work upon different components. This link (
forum.appian.com/.../BPM_Application_Delivery_-_Actualize)
will give you an idea to how to decide components so that multiple users can work upon same projects.
#1. So, before actual development, find out the common functionalities in different parts of the process and which users going to utilize and divide the process in number of components.
As you decides you sub processes and main process. The sub process are modeled by different users and the developer of main process directs the sub process node to a dummy PM (having only start and end event with no pv!s). And when the dev of sub process completes only the mapping of variables remains.
To avoid confusion of variables, a common pattern is decided before hand.
Many other activities can be done in parallel like process, dashboard/Records, Reports.
#2. person X assumes that person Y will be providing that data at some point of time when all the mapping as stated in #1 is done.
#3. While in iterative development, the required enhancement should not disturb the functionality of currently running instances. Eg: user should not change the number of parameters of existing rules (which are already in production). This may result that PM is of older version which takes let say 3 input for rule and the rule is modified and take only 2 parameters, then the current running instances will give error.
Hope this helps.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data