...
The first feedback the project receives is that users are having a hard time finding these in the list. It turns out that at this institution the natural ordering is by course number, not name. The second feedback is to further filter the list to show only those departments to which the user is authorized to create courses. The application programmer negotiates with the product owner to forget the authorization thing and he'll figure out some way of resorting but of course re-sorting the data conditional upon corporation continued cooperation from this the OSID implementation programmer.
...
While the OSID implementor struggles to solve this dilemma (how can I do it both ways at the same time?) he starts to yearn for the days application programmers used were allowed to use SQL directly. The application programmer is also regretting this little endeavor and suggests goes on to advise the product owner to set up his their own database of organizations that the project can controlcan be controlled without having to negotiate the service contracts.
Intervention
In our not so made up example, we have three roles at this party. A product owner, an application programmer, and an OSID implementation programmer. While the product owner should understand the business and priorities well, a product owner may not be able to see what is happening architecturally. The application programmer knows how to build applications, and with each iteration cares less and less about what he's told about how things ought to work in an enterprise. The OSID implementation programmer has no visibility into the business while wandering into the role of infrastructure provider for all people. The development process starts to rattleis in trouble.
We're missing the architectural view. If the "architect" shows up with stack diagrams showing how AngularJS, Spring, Hibernate, and MySQL relate to each other, thank them and find a services architect who can slice through this problem before it gets worse.
...
Coming in late to the party, the service architect has to deal with both the organization desire to treat these services as a multi-use infrastructural component reusable infrastructural components but also has to be able to solve business-specific needs and relieve the mounting tension on the project. A lot of back and forth has occurred to list effort has already been expended to display a list of 22 departments that won't change in the lifetime of this project. The first thing the service architect does is whip together a simple Resource OSID Provider that stores the 22 Resources in a hashmap and spits them out in the right order. She instructs the application programmer to go back to his first version:
...
There is more to organization management than the Resource OSID delivers. The Resource OSID is used as an abstract reference in the Course because a Course sponsor may be an organization, an individual person, a Program, or all of the above. Because it is referenced This abstract reference does not necessarily mean that it is the best OSID to interface with manage the underlying data. Our trusty service architect is familiar with the service definitions and begin . She begins building up from the Org org tables in the data warehouse by first selecting the OSID that makes the most sense and working out from there. The service architect divides this overall problem in two major pieces separating to separate what the course application needs from what is the best fit for the organizational data. Conquering Closing the gap will be of later concern.
The Personnel OSID defines Organizations. Unlike Resources, Organizations are both Temporal and Federateable. This means that the dates in which an Organization is effective and the multi-parented hierarchical relationships are designed into the this service. The OSID implementation programmer is charged with implementing the OrganizationLookupSession and OrganizationHierarchySession of the Personnel OSID and will be able to do this so without making any assumptions about active states or genus Types. The divide and conquer strategy is removing assumptions (business logic) from both the application and the underlying provider.
...
The service architect removed the assumptions to what an "applicable" organization is from both the application and the base Personnel OSID Provider. It also removed the assumption that as to what is "active" (org.isEffective()) should be only evaluated based on the current time as , it now will also be evaluated against the current "context" time)."
This Resource OSID Provider is the place where this "business" logic resides and although it is not as reusable as the other components of this system (more touch points and agreements), it is also fairly lightweight.
...