Message-ID: <672682020.70347.1448768421346.JavaMail.confluence@ece-vmapps> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_70346_826987972.1448768421345" ------=_Part_70346_826987972.1448768421345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
As outlined in Section IV of our METIS paper, in order to meet GSIM's objectives= to enable communicating, educating and collaborating, I, with my IMF colle= agues, feel the model needs fewer objects overall, and these objects should= be at a higher level.
Successful education connects to people=E2=80=99s everyday life. It is f= acilitated by creating a =E2=80=9Csimple, easy to understand view of comple= x information, with clear definitions=E2=80=9D (GSIM Brochure).
Creating an easily understood view also helps people collaborate. Workin= g with others using a shared language and a common understanding helps part= icipants feel they belong to a group much bigger than their work unit, thei= r project team, or even their organization.
With GSIM, potential users must =E2=80=9Cbuy-in=E2=80=9D at the most det= ailed level of the model. There is no rigorous, agreed and coherent pi= cture at any level above the specification, which, at nearly 300 pages, is = not a usable tool for educating or collaborating.
My IMF colleagues and I believe GSIM needs a model of up to 50 high leve= l objects as its main organizing scheme - this was echoed in the Metadata Flows paper at METIS. This model= would stand as an analogue to the GSBPM model of sub processes. The two co= uld operate in tandem as tools to educate and collaborate.