Welcome to the IDIOM Software Blog.

    ’InHousing’ Idiom development

    Mark Norton  12 August 2011 01:49:31 PM
    This discussion arose from an Idiom client who is looking to transition from an Idiom services dependency to full in-house development and support. As the client is keen to remind us, we do say on our website that ‘we will never lock you in!’

    The project in question is a turnkey development that will perform loan screening for multiple banks. With a total of 2-3 people involved in the development from the Idiom side, it is relatively small in traditional development terms, and is managed directly between the Idiom decision designer and the client buyer.

    It includes 8 decision models (generating ~60,000 lines C#) and a similar number of Idiom Forms, some quite complex.

    The project has three notable development threads, with approximate relative effort shown below.

    ·        Idiom Decision Manager - 42%;

    ·        Idiom Forms - 16%;

    ·        ASP.NET application - 42%.

    The Idiom Decision Manager [IDM] percentage includes all project management, analysis and design overhead - that is, all analysis, documentation, meetings, etc. This is likely to be 50% of the total ‘IDM’ effort. This bundling of requirements and solution design with decision design and automation is not unreasonable – Idiom sees itself primarily as a business requirements specification environment rather than a development tool, even though the resulting decision models are all generated as ready-to-run computer code. As Idiom users will be aware, the decision designs explicitly drive forms development (in the case of Idiom Forms) and implicitly drive all other technology requirements and designs. Therefore, the IDM development thread is the senior design and development stream in the overall development.

    The ASP.NET component is building infrastructure to service the decision models. Each new project for the client should require less additional infrastructure as we go forward.

    It is important to note that the very great majority of the client 'product specific' development occurs in the Idiom Decision Manager thread.

    Taking the above comments into account, we expect the relative resource consumption percentages to change on a go forward basis. Therefore, a likely 'next project' resourcing  could look like the following in terms of relative resource time:

    • Analysis, design, planning: 20% [C]
    • Idiom Decision Manager: 20-30% [B]
    • Idiom Forms: 10-15% [E]
    • ASP.NET: 20-30% [D]
    • Testing and Production: 15-20%  [A]
    Our discussion point is the transition of skills and responsibilities to the client. Note that project management is not included – with the typical small project that Idiom encourages (1-3 people) project management does not need dedicated resourcing.

    The letters A-E indicate a likely sequence of skills transition between Idiom and the client.

    'A' is where we suggest the client focuses resource development in the first project delivery. Somebody who is doing in-depth testing will develop a good understanding of what the system does and should do. This is an essential foundation for B.

    'B' is next off the rank. The knowledge developed by 'A' will provide good background for transitioning to 'B'. Development of the Idiom Decision Models does not require technical skills - it requires good domain knowledge and a detailed, analytical mind, similar to the tester but extending into more creative territory (Excel development is a comparable task).

    The 'B' resource will have the best perspective of the overall system from a business delivery perspective - that is, what it does for the business. To put it more emphatically, they are likely to become the key knowledge resource as well as the custodian of the core IP of the organization. This person should therefore be a competent, ‘self actualized’ person with an eye for detail and a delivery focus.

    Given the focus and aptitude of the ‘B’ resource, they will become a key player in the ‘C’ resource effort – they will be the domain expert for the project AND the key delivery resource for business functionality.

    If we now switch to the other side of the project, the technical side of the application represented by D. The ASP.NET (or Java if a Java application) delivery is a traditional technology driven development, although in an Idiom centric development the technical plumbing is much (up to an order of magnitude) smaller than in a traditional development.

    The technology development is about building operational systems capability, whereas the Idiom development is about directing and controlling that capability (plus of course, capturing the core business IP in an executable form). However, once the capability is built, it stays built, so that there is a flush of development that is required to build the initial capability. The first few projects will all add to the capability ‘critical mass’, but once a critical mass of capability is reached, the incremental development requirement will slow down.

    The point at which the ‘D’ skills interface with the A-C skills is at the analysis, design, and planning stages. New business requirements must be mapped to existing, modified, or new capabilities - the decision models can’t control what doesn’t exist. Therefore the D skills also participate in the ‘C’ skill area (the infamous analyst/developer). In a well formed, light-weight project, C is in fact represented by the B and D resources and has no resources of its own.

    Finally, we have the E skills. In general, the Idiom Forms skillset is light weight and localised. Some forms development is quite technical, and some entirely declarative. Generally, the more technical parts of Forms development (for instance, bespoke behavior attached to buttons) will be easily addressed by the ‘D’ skills. This leaves the Forms developer with a need to acquire easy to learn ‘Idiom Forms Builder’ declarative skills plus technical styling skills – specifically CSS. This sort of skill set could be picked up by any of the above skill types, and/or by junior and lower paid staff like students, testers, junior developers etc.

    In summary, in building out the client in-house support capability, we suggest that:

    1.        Get the A + B skillsets in one person. This will deliver the biggest bang for the buck – immediate and  direct business control of the technology, and of the core business IP that is embedded in the technology. Allow 1 week working with an Idiom consultant to acquire adequate Idiom Decision Modeling skills.

    2.        With the correct person in place above, they should readily extend to the ‘C’ skills? Look for competent technical design skills in the ‘D’ developer to supplement any technology weakness in the A/B/C resource.

    3.        The D skills are the biggest concern and biggest risk. Because of the smaller development load that is inherent to the approach, this person is likely to be a sole charge developer, and needs to be competent across a number of technical areas (web, application coding, database, frameworks, design). This person will become a core technical resource if successful, or an expensive waste of lots of money in addition to their own salary if not. Obviously only the former is acceptable.

    4.        The E skills tasks can be done by a combination of D and the A/B/C resources in the early stages. When the project has achieved its primary objectives, bring in a junior staffer to provide some degree of additional support and redundancy. This person can pick up the routine forms development and testing which is typically viewed as menial by the more senior A/B/C/D staff. Allow 1 week working with an Idiom consultant to acquire adequate Idiom Forms building skills.

    Finis