Comments on: Preserving the Model http://www.bp-3.com/blogs/2009/02/preserving-the-model/ A Blog about Enterprise BPM and Business Process Improvement by the folks at BP3 Sat, 11 Feb 2012 20:01:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Scott Francis http://www.bp-3.com/blogs/2009/02/preserving-the-model/comment-page-1/#comment-135 Scott Francis Tue, 17 Feb 2009 03:46:47 +0000 http://www.bp-3.com/blogs/?p=468#comment-135 John - The notion of different "aspects" I've thought of as "layers" - ie, why can't we look at the same model, but see different levels of detail or different types of information overlayed on the same basic bones of process....? The example I would give is the basic anatomy book with the transparent overlays over the skeleton... you can see the skin, then peel that back and see the muscles, the peel that back and see the organs... etc... And though each layer adheres to the model, it informs the model further, and to the right audience is super-useful... And to the wrong audience the user can either delve deeper to the level they need, or higher to the level of comfort.... John –
The notion of different “aspects” I’ve thought of as “layers” – ie, why can’t we look at the same model, but see different levels of detail or different types of information overlayed on the same basic bones of process….?

The example I would give is the basic anatomy book with the transparent overlays over the skeleton… you can see the skin, then peel that back and see the muscles, the peel that back and see the organs… etc… And though each layer adheres to the model, it informs the model further, and to the right audience is super-useful… And to the wrong audience the user can either delve deeper to the level they need, or higher to the level of comfort….

]]> By: Scott Francis http://www.bp-3.com/blogs/2009/02/preserving-the-model/comment-page-1/#comment-4572 Scott Francis Tue, 17 Feb 2009 03:46:00 +0000 http://www.bp-3.com/blogs/?p=468#comment-4572 John - The notion of different "aspects" I've thought of as "layers" - ie, why can't we look at the same model, but see different levels of detail or different types of information overlayed on the same basic bones of process....? The example I would give is the basic anatomy book with the transparent overlays over the skeleton... you can see the skin, then peel that back and see the muscles, the peel that back and see the organs... etc... And though each layer adheres to the model, it informs the model further, and to the right audience is super-useful... And to the wrong audience the user can either delve deeper to the level they need, or higher to the level of comfort.... John –
The notion of different “aspects” I’ve thought of as “layers” – ie, why can’t we look at the same model, but see different levels of detail or different types of information overlayed on the same basic bones of process….?

The example I would give is the basic anatomy book with the transparent overlays over the skeleton… you can see the skin, then peel that back and see the muscles, the peel that back and see the organs… etc… And though each layer adheres to the model, it informs the model further, and to the right audience is super-useful… And to the wrong audience the user can either delve deeper to the level they need, or higher to the level of comfort….

]]> By: johnreynolds http://www.bp-3.com/blogs/2009/02/preserving-the-model/comment-page-1/#comment-134 johnreynolds Tue, 17 Feb 2009 00:53:57 +0000 http://www.bp-3.com/blogs/?p=468#comment-134 I've thought about this a lot, and will most likely <a href="http://thoughtfulprogrammer.com/" rel="nofollow">blog</a> about it further... but what's generally missing in Software Engineering are the mechanisms necessary to "lock down" functional business requirements in a way that prevents developers from (hopefully unintentionally) modifying them. In the specific case of BPMN - I think we need to explore "Aspects"... the business "owns" the functional business requirements, including process flow and rules. Developers clearly "own" other aspects, but they should be locked out of changing that which they should not. If these aspects can be clearly delineated, then the business guys can look at the business aspects without the developers crud, and perhaps visa versa. -John I’ve thought about this a lot, and will most likely blog about it further… but what’s generally missing in Software Engineering are the mechanisms necessary to “lock down” functional business requirements in a way that prevents developers from (hopefully unintentionally) modifying them.

In the specific case of BPMN – I think we need to explore “Aspects”… the business “owns” the functional business requirements, including process flow and rules. Developers clearly “own” other aspects, but they should be locked out of changing that which they should not.

If these aspects can be clearly delineated, then the business guys can look at the business aspects without the developers crud, and perhaps visa versa.

-John

]]> By: johnreynolds http://www.bp-3.com/blogs/2009/02/preserving-the-model/comment-page-1/#comment-4571 johnreynolds Tue, 17 Feb 2009 00:53:00 +0000 http://www.bp-3.com/blogs/?p=468#comment-4571 I've thought about this a lot, and will most likely <a href="http://thoughtfulprogrammer.com/" rel="nofollow">blog</a> about it further... but what's generally missing in Software Engineering are the mechanisms necessary to "lock down" functional business requirements in a way that prevents developers from (hopefully unintentionally) modifying them. In the specific case of BPMN - I think we need to explore "Aspects"... the business "owns" the functional business requirements, including process flow and rules. Developers clearly "own" other aspects, but they should be locked out of changing that which they should not. If these aspects can be clearly delineated, then the business guys can look at the business aspects without the developers crud, and perhaps visa versa. -John I’ve thought about this a lot, and will most likely blog about it further… but what’s generally missing in Software Engineering are the mechanisms necessary to “lock down” functional business requirements in a way that prevents developers from (hopefully unintentionally) modifying them.

In the specific case of BPMN – I think we need to explore “Aspects”… the business “owns” the functional business requirements, including process flow and rules. Developers clearly “own” other aspects, but they should be locked out of changing that which they should not.

If these aspects can be clearly delineated, then the business guys can look at the business aspects without the developers crud, and perhaps visa versa.

-John

]]>