In This Edition
1. Quotations to Open On
2. Feature Articles
2.1 The Case for using Competence Assessment within the INCOSE Systems Engineering Professional (SEP) Program by Ian Presland
2.2 Enterprise System Engineering: Applying Enterprise and Architecture in the Practice of Enterprise Architecture by Marc H Gewertz
3. Additional Articles
3.1 Why Collaborations Fail by Jon Huggett
3.2 Integrating Program Management and Systems Engineering by Ralph Young
4. Systems Engineering News
4.1 INCOSE Launches New Systems of Systems Primer
4.2 New Purdue Center to Develop Scientific and Engineering Principles of Resilient Systems
4.3 Computer Science Research Is Lacking In These Key Areas
4.4 SysML V2 Status
5. Featured Organizations
5.1 Massachusetts (USA) Institute of Technology (MIT) Sociotechnical Systems Research Center (SSRC)
5.2 MIT Consortium for Engineering Program Excellence (CEPE)
6. News on Software Tools Supporting Systems Engineering
6.1 Schedule Compliance Risk Assessment Methodology (SCRAM)
6.2 Siemens Teamcenter® PLM software embraces SysML and Integrates with Capella
7. Systems Engineering Publications
7.1 Engineering Emergence: A Modeling and Simulation Approach
7.2 Building High-Performance Project Talent — A Transformational Initiative
7.3 Systemic Change Management: The Five Capabilities for Improving Enterprises
7.4 Program Management
7.5 Don’t Jump to Solutions: Thirteen Delusions that Undermine Strategic Thinking
7.6 Journal of Change Management
7.7 Engaging Stakeholders for Project Success
8. Education and Academia
8.1 University of Southampton Hosts International Conference for Safety Critical Systems Software
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
10.1 ISO/IEC 33001 Updates ISO/IEC 15504 Series
11. Some Definitions to Close On
11.1 Change Management (CM)
11.2 Key Stakeholder Management Definitions
11.3 Basic and Fundamental Definitions for Use in the Practice of Enterprise Architecture
12. Conferences and Meetings
13. PPI and CTI News
14. PPI and CTI Events
15. PPI Upcoming Participation in Professional Conferences
1. Quotations to Open On
“Rarely is proceeding in ignorance of what is known or knowable about “the problem” a part of
the formula for achieving the best result.”
Robert John Halligan
“Forgiveness does not change the past but it does enlarge the future.
When you make a commitment, you build hope. When you keep it, you build trust.
May your choices reflect your hopes, not your fears.”
Nelson Mandela
“Why do we only rest in peace? Why don’t we live in peace, too?”
Petrol pump wisdom provided by a Johannesburg South Africa filling station
2. Feature Articles
2.1 The Case for using Competence Assessment within the INCOSE Systems Engineering Professional (SEP) Program
by
Ian Presland
Charterhouse Systems Limited
Email: ian@charterhouse-systems.com
Copyright © 2018 by Ian Presland. All rights reserved.
Abstract
In 2004, the International Council on Systems Engineering (INCOSE) introduced the Certified Systems Engineering Practitioner (CSEP) designation, to provide a formal method for recognizing the education, experience, and knowledge of systems engineering professionals.
While CSEP numbers continue to grow globally, in some countries, the increase in the number of CSEPs has been lower than expected. In the United Kingdom (UK), one reason commonly cited for this is that the CSEP program includes minimum “time-served” experience requirements, meaning that it does not align well with current “competence-driven” Human Resources (HR) systems and, more critically, the time-served elements of CSEP may be seen as failing to meet current European Union (EU) age discrimination legislation.
For some time, the use of a competence-based approach to the assessment of CSEP experience has been postulated as an alternative approach; if successful, the revised approach would eliminate these issues, enabling the SEP program to grow significantly in these areas.
In mid-2017, the author led a UK Chapter pilot on behalf of INCOSE, exploring the use of competence-based experience assessment as part of the CSEP application review activity. This article presents the case for “competence-based CSEP” in detail and suggests a potential way forward.
The views expressed in this article are those of the author and do not necessarily represent those of INCOSE UK or INCOSE.
Introduction
In 2004, the International Council on Systems Engineering (INCOSE) launched its Systems Engineering Professional (SEP) program with the introduction of the “Certified Systems Engineering Professional” (CSEP) designation. This provided a formal method through which practitioners in systems engineering could have their education, technical knowledge, and experience independently validated by INCOSE-accredited assessors.
The program later added an introductory level (below CSEP) called “Associate Systems Engineering Professional (ASEP)”, and an advanced level (above CSEP) called “Expert Systems Engineering professional (ESEP)”. The program currently recognizes around 2800 SEPs[1] across these three levels worldwide.
However, while CSEP numbers continue to grow generally, in some countries, the increase in the number of CSEPs has been lower than expected. In the UK and Europe, one reason commonly cited for this is that the CSEP program includes time-based measures of experience as a proxy for acquired “competence”. The inclusion of these time-based elements means that the CSEP designation cannot be readily integrated into corporate HR job descriptions or competence-development frameworks; and, more critically, mandating CSEP as a job pre-requisite could arguably be viewed as failing to meet current European Union (EU) age discrimination legislation[2]. Details concerning this matter are discussed later in this article.
Furthermore, while the current CSEP program requires that “depth” and “breadth” of experience be documented, there are no criteria characterizing an acceptable minimum set of skills; robustly proving you have an appropriate duration of experience in the area is deemed sufficient. Therefore, two candidates documenting similar depth and breadth could have rather different skills profiles.
Does this matter? Perhaps not. They are “the same” because both have documented experience performing tasks defined by INCOSE as part of the technical area definitions and both meet the minimum “months of experience” requirements. The CSEP designation is intended to be a guide. However, since there is no mandated set of required experiences, there is currently no guarantee either would have the necessary knowledge and understanding to be able to perform any selected task in a technical area, even if that task was generally regarded as “core” within the profession.
These challenges have stymied acceptance and therefore growth of the SEP program, particularly in the UK, leading to calls for INCOSE to offer a competence-based assessment mechanism, which would comply with the legislation and also set explicit criteria for demonstrating “competence” in key tasks within each technical area.
The merits and challenges of such an approach and an overview of INCOSE’s ongoing activities in this area are discussed in detail below.
Existing INCOSE CSEP requirements
The first step of the current CSEP application process requires an individual to submit a written summary of their work experience, broken down into 15 INCOSE-specified systems engineering (SE) technical areas defined as a key part of the Certification process and which together encompass the full scope of the systems engineering discipline[3].
Assuming the individual has a qualifying technical bachelor’s degree [Ref 6, INCOSE] they are required to submit evidence of at least 60 months of experience, including a minimum 12 months in at least three of the 15 technical areas. All experience claimed is required to be verified by independently-assessed references, who themselves need to submit evidence demonstrating they both know the candidate’s work and understand systems engineering before they can be approved as qualified references [Ref 5, INCOSE].
It should be noted that merely stating that you have “x months of experience in y or z” is in no way a guarantee your experience will be deemed valid – even if the tasks appear sensible and you have a reference corroborating your claim. Assessors are trained to “read between the lines” and look at the broader picture of evidence submitted when reading an application. Assessors may determine that some (or all) of the claimed experience is not adequately supported by evidence, reference validation or both. This regularly leads to review teams going back to applicants or their references to try to obtain clarity or improved evidence.
Finally, assuming the above evidence is (eventually) accepted, to be formally designated a CSEP, the applicant needs to pass a knowledge examination based upon the INCOSE Systems Engineering Handbook [Ref 8, INCOSE SEH].
Clearly this is a tough set of criteria to meet, and as an application reviewer, the author can vouch for the skills, dedication, and professionalism of reviewers and the rigorous, consistent application of the defined process by an INCOSE Certification team.
The existing process is not without its challenges. However, the INCOSE Certification team continues to work to improve it, as they have done since its inception.
The “time-served” element
One area of concern is the inclusion of time as a proxy indicator of acquired competence. Assuming the applicant has a qualifying technical bachelor’s degree [Ref 6, INCOSE], there are two time-related requirements:
- The time which needs to be served to acquire appropriate “depth” of experience is required to be a minimum 60 months.
- Within this 60-month period, “breadth” is required to be demonstrated by documenting at least 12 months of experience in each of at least three of 15 technical areas defined by INCOSE.
As stated in the introduction, in the UK and EU at least, while no court case has yet tested this, legal opinion in many organizations is that these requirements could be viewed as “indirect age discrimination” under EU law. This means Certification at CSEP level cannot currently be mandated as a pre-requisite when recruiting candidates. Furthermore, individuals cannot be seen to be financially benefitting from being a CSEP either, as this would potentially also be an indirect age-discriminatory practice[4].
There are other implications of setting a bar fixed at 60 months. The question arises: “Is an applicant documenting just 58 or 59 months of experience automatically unqualified as a systems engineer, whereas one with 60 or 61 months is somehow transformed into a “qualified” applicant?” In fact, the CSEP rules indicate an applicant with just 59 months would normally be denied CSEP whereas one with 60 months would normally be successful[5].
The “breadth” time-served requirement is similar. The CSEP rules require 12 months in each of three or more areas. So, would 11 months in one or more of the three areas be unacceptable?[6]
Finally, with an increasing number of individuals now choosing to work part-time [Ref 9, OECD], [Ref10, ONS], “60 months” of experience will take proportionately longer to accrue. For instance, an individual working just three days per week would need to have worked for well over 8 years to acquire 60 months of experience. Is this truly reflective of their developing ability to perform systems engineering tasks? The author’s experience is otherwise. However, opinion is divided in this area, although it is clear that the ability of any individual to work effectively in a part-time role will depend both on the individual and the role they are required to perform.
Despite these challenges, setting the “experience” bar at the 60-month fixed level has significant merits. It is simple to explain, quantifiable to applicants, and can be validated simply by counting the number of months in each area within an experience “summary table” mandatorily supplied as part of the application (validation occurs only after deduction of claimed experience dismissed by reviewers as not representing systems engineering, lack of evidence, or reference support).
A “Minimum Viable Systems Engineer”?
While the current system comprehensively defines appropriate activities within each of the 15 technical areas, it does not mandate a prerequisite set of activities within each area and also does not forbid any combination of technical areas to be documented in an application. This is deliberate: it offers flexibility so those from vastly differing backgrounds can apply without prejudice.
The downside is that there is no “minimum skill set” defined for a systems engineer at the CSEP level. Therefore, successful applicants cannot be guaranteed to have performed any stated activity either generally or within a single technical area – even if some tasks within an area might be regarded as “core” by the wider systems engineering community. Instead, reviewers use submissions of references and their own judgement to determine whether the applicant has sufficient diversity of experience.
Equally, regarding “breadth” of experience, an applicant may have spent their 12+ months within a single technical area performing a limited set of tasks and thus may not have gained the insight of, say, another applicant exposed to diverse experiences over a shorter time. Once again, the existing process relies on the skills and expertise of reviewers who are trained to deduce scope of experience from the written application (or through clarifications) although currently consistency is by no means guaranteed between applicants (other than in line with the stated rules). But while the current process does not explicitly demand any diversity of experience within a technical area, there is no reason why it could not be modified to incorporate a minimum experience criteria set which would help improve consistency and confidence in outcomes.
Additional challenges
Coupled with all of the above, assessors regularly face further challenges in written submissions:
- Quality of written submission. Individuals regularly fail to document their experience to the depth required, or fail to identify the specific systems engineering tasks they have performed. This can be improved by coaching the applicant, but remains a common failing in submissions. Usually candidates (or their references) need to be contacted for additional clarifications.
- Quality of reference validation(s). References may be glowing, but often lack technical substance. Again, references often need to be contacted to supply more detail.
Activity Classification. The choice of area in which the candidate categorizes their technical experience (from the 15 available) may differ from the area selected by their reference for the same element of experience. While this is completely acceptable, it can lead to an apparent lack of alignment between candidate and reference write-ups, potentially undermining the credibility of an application, reference or both[7]. Reviewers are trained to be aware of this and work hard to align submissions from references and candidates.
INCOSE SEP Certification Application Reviewers (CARs) spend much of their time addressing the above issues. However, the need to go back to applicants and references for additional clarification consumes additional precious volunteer effort and requires more applicant and reference time.
The underlying limitation is that reviewers are dealing solely with written submissions and clarifications. The current CSEP program does not include any form of verbal interaction with either applicant or reference. An oral interview would provide an opportunity for reviewers to gain a targeted insight into any area of an application which causes concern, for whatever reason[8] [9].
Competence-based assessment
“Competence” is defined as the “behaviors …and technical attributes … that individuals must have, or must acquire, to perform effectively” [Ref 2, CIPD].
Competence-based assessment requires an individual firstly to submit paper-based evidence (with validating references) identifying examples where they have gained experience against a series of competence “indicators” defined for each technical area. The “indicators” represent common (or mandatory) examples of key activities within the area where evidence is required. This paper-based evidence is reviewed and is usually followed up with an interview by one or more trained assessors, who supplement the written evidence with oral evidence gained from additional ad hoc questions designed to confirm or clarify an individual’s current level of competence.
Competence-based interviewing is by no means new and its advantages over a traditional review of employment history and references are well-established [Ref11, SHRH]. Importantly, this approach does not rely on any direct measurement of “time”. While time is undoubtedly a factor for an individual in gaining the necessary experiential evidence to be deemed “competent”, the precise amount of time is not fixed.
As stated previously, in the UK and European Union (EU), the introduction of legislation prohibiting discrimination on the grounds of age almost a decade ago led to the “competence-based” approach (as opposed to the traditional “time-served” approach) becoming the default method of assessment of an individual’s ability to do a task (or take on a role).
Indeed, the UK Chapter of INCOSE set up a specialist working group in 2007, with the target of generating a Competence Framework for Systems Engineering in part to address this issue. By 2010 the INCOSE UK Systems Engineering Competency Framework [Ref 7, INCOSE UK CF] was mature enough to be actively used by several organizations. It was subsequently adopted as an INCOSE product and its use expanded further globally.
Assessing competence using the UK Chapter framework
The INCOSE UK Competence Framework characterizes systems engineering using 23 competence areas rather than the 15 technical areas used in the INCOSE SEP program. However, the 15 INCOSE technical areas can be generally mapped across: both approaches are merely characterizing systems engineering through different viewpoints[10].
The INCOSE UK document provides a set of well-defined assessment criteria or “indicators” for each of the 23 areas. These form the basis of the assessment activity. This goes further than a general review of documented activities performed, since each indicator is explicitly required to be verified through evidence, defining a minimum requirement for core experience breadth and depth.
In support of the assessment, an individual must provide written (and reference-validated) evidence for each indicator for the level required. The result of the assessment is an individual’s competence profile stating, for each of the assessed areas, which indicators have been demonstrably “met” through evidence and the resulting “level” of competence at which an individual is currently working. This can be compared against specific level requirements for any role within the business.
Evidence could be written by the applicant, obtained from reliable references within the business, or both. The assessment of such evidence follows a route similar from the current CSEP assessment. Well-documented experience with good quality evidence and reference support can generally be taken as acceptable. Applicants and references can both be contacted to re-submit written evidence to reduce uncertainty and ambiguity.
However, since the competence assessment normally includes an interview, any written area of submission can be checked, challenged, or supplemented through additional “open” questions[11] at the interview, designed to confirm or clarify whether the candidate is indeed operating at the competence level claimed. Those who have submitted high-quality applications will likely have a shorter interview than those whose application gave concern, but the option is always available.
The value of competence-based assessment
In summary, there are three key factors through which the competence-based approach adds value:
- An objective set of indicators is defined for each technical area. Each “indicator” requires acceptable evidence to be provided for a defined competence “level” to be deemed achieved.
- The use of an interview supplements the paper-based evidence.
- “Time” is not a factor in assessing competence. Either an individual has or has not demonstrated to the assessors’ satisfaction that they have successfully met the indicators defined for any given level of competence.
The last of these points is particularly important as it removes the legal barrier to mandating CSEP as a pre-requisite for roles in the EU. Currently a requirement for CSEP can only be stated as “desirable” (or similar) as time is a factor in the award process. With the time constraints removed, organizations could consider mandating CSEP Certification as a pre-requisite for certain Systems Engineering roles. This would help further promote CSEP as the “must-have” professional baseline qualification for Systems Engineers in the same way that similar certification schemes have become prominent in the project management profession.
More generally, a competence-based approach would:
- Provide reviewers with a chance to question any aspect of a candidates claimed experience during the interview. This goes well beyond a review of paper alone and helps ensure judgements in borderline cases are more likely to be accurate.
- Enable CSEP to be linked to an overarching competency framework, with indicators defining the minimum acceptable competence levels for each technical area, improving alignment of core skills across the wider CSEP community. With the recent release of the new INCOSE Competency framework [Ref 12, INCOSE CF], this becomes a real possibility, although completion of the assessment criteria for this framework is still ongoing which means that updating the competence-based assessment mechanism to capitalize on the new framework, while straightforward, will need to wait until the associated criteria have been formally agreed and published[12].
- Reflect best HR practice and thus in many organizations could facilitate the integration of systems-engineering competence development and the SEP program directly into engineering career development paths.
The CIPD defines additional general benefits of competence-based regimes as [Ref 2, CIPD]:
- Appraisal and recruitment systems are fairer and more open.
- Recruiters can assess transferable skills and identify required behaviors regardless of career background.
- There is a link between effective individual inputs to work and organizational performance.
- Employees have a well-defined set of behaviors required in their work and are clear about how they are expected to perform their jobs.
- Processes are measurable and standardized across organizational and geographical boundaries.
A competence-based CSEP coupled with the newly-released INCOSE Systems Engineering Competency Framework would define an industry-transferable assessment mechanism, supporting all aspects of systems engineering capability development. This would raise the profile of systems engineering as a discipline with the potential for new revenue streams for INCOSE.
Moving forward
In mid-2017, the author was responsible for leading the INCOSE UK Chapter in performing a competence-based experience assessment pilot for CSEP candidates on behalf of the wider INCOSE.
The pilot addressed the key areas discussed above: it pre-defined a set of mandatory indicators required to be deemed “competent” in each technical area; competence was assessed using face-to-face interviews; and a “profile” of required minimum experience across the “V” lifecycle was mandated rather than allowing applicants to choose from all available technical areas.
The pilot used the INCOSE UK Competency Framework for assessment as it provided a well-established and complete set of indicators. Furthermore, the 23 technical areas identified in that framework were “grouped” broadly into “Systems thinking”, “Requirements engineering”, “Left” and “Right-hand” sides of the “V” lifecycle, “System implementation” and “Systems engineering management” with candidates having to demonstrate competence in a technical area within each of the six groups – thus enforcing a “breadth” profile requiring some element of experience “across the lifecycle”[13].
Each assessment team comprised two experienced assessors[14]. They examined the breadth and depth of pilot candidates’ systems engineering experience using well-established competence assessment interview techniques, against a profile agreed by the INCOSE Certification Advisory Group (CAG), the body responsible for overseeing the entire INCOSE SEP program, as “equivalent to CSEP”[15]. Both interviewers had to agree on the outcome “Pass” or “Fail”[16].
Pilot candidates also completed a standard CSEP application in order that their experience could be separately reviewed by a team of qualified INCOSE Certification Application Reviewers following the existing application review process and the results of both approaches compared.
While the results of this pilot have yet to be published, the pilot team’s conclusions were that the competence-based approach not only proved to be a viable alternative to the current mechanism but showed potential to reduce or eliminate both “time” and “experience” issues. Pilot applicants were also pleased with the process.
Challenges with introducing a competence-based approach
One of the main criticisms of competence-based assessment is that it is costly and unwieldy [Ref 2, CIPD]. Clearly the verbal assessment face-to-face interview is resource intensive: Pilot CSEP interviews took approximately two hours (plus preparation and outcome write-up time) and involved coordinating the schedules of two assessors as well as the applicant when setting-up an interview slot. Although interviews
were mostly face-to-face, pilot assessors have conducted telephone based competence-assessment interviews and believe there would be no significant degradation in quality if this approach was taken instead. This would represent a more practicable route moving forward.
In fact, the overall reviewer volunteer time commitment compares well to the current process which involves three reviewers who typically spend between 1-2 hours each reviewing the paperwork (even longer if additional clarifications are required). However, the administration effort coordinating conference calls for interviews is likely to remain somewhat higher with the competence-interview approach than with the current asynchronous email-based system (although a technology-based interview scheduling system could potentially reduce this overhead in time).
Competence-based assessors must be trained. They need to understand how to perform a competence-based interview, the full scope of each competence area and the nature of qualifying evidence sought in validation of competence indicators. They also need to be able to interpret qualifying evidence and terminology across different systems engineering domains. However, CAR reviewers within the current approach also require training, so while the scope of training may differ, the overall SEP program impact is arguably small.
Some of the criticisms levelled at the existing approach still apply, and some new ones arise:
- To keep interviews at a reasonable duration, written evidence well-supported by references and other evidence is unlikely to be challenged – although at least there is now an opportunity to ask a question at the interview as a cross-check;
- A well-coached applicant skilled in verbal communication may find the process easier that one who is not, or where their first language is not that of the interviewer;
- Candidates nervous because of the formal interview may not perform as well as they should;
- The assessed level of competence is still subjective as it involves human interactions.
As with the current CSEP process, it is the experience and training of reviewers that comes into play when assessing nuances of candidate responses. However, the opportunity for two interviewers to question a candidate directly is an effective way to reduce risk of error or disagreement among assessors[17].
Summary and conclusions
INCOSE’s SEP program is well established, and professionally run. Furthermore, it has achieved excellent acceptance in many counties, and the number of SEPs continues to grow. For many, it offers a simple, objective, cost-effective, and defendable approach, defining a fixed “bottom-line” for minimum acceptable experience for CSEP. It remains a straightforward option for individuals whose breadth and depth of experience is non-controversial or for organizations where legal requirements permit a “time-served” measure of assessment.
Offering a competence-based assessment alternative would provide flexibility when assessing duration of experience without compromising quality or consistency. It could prove useful as part of a wider career development and assessment mechanism for individuals and organizations, enabling developing competence to be tested against well-defined indicators en-route to applying for competence-based CSEP. It could also encourage high performing, fast developing individuals or those with unusual technical backgrounds to apply for CSEP assessment, especially if their experience months were insufficient or they felt their experience needed verbal clarification. There is even an argument that those with national security concerns could potentially be assessed through an extended oral interview, using cleared assessors without having to commit any secure information to an application form.
Most importantly however, it would be of prime importance in markets where legal requirements prohibit use of “time-based” criteria, thus enabling organizations to consider mandating CSEP for roles for the first time.
The inclusion of a requirement for evidence against a pre-defined set of competence indicators for each technical area helps improve consistency between assessments, while defining a mandatory “lifecycle profile” of competence provides an additional opportunity standardize core skills demonstrated through CSEP. Although piloted as part of competence-based assessment, these two concepts could also be considered as enhancements to the existing CSEP program.
Furthermore, learning and feedback from implementing a competency-based approach could also be used to improve the understanding of minimum criteria and expectations for each of the technical areas within the existing approach, helping to improve consistency in the expectations of skills for certified individuals.
Assuming the new INCOSE Systems Engineering Competency Framework is adopted by organizations globally, this will further reduce the risk to organizations and individual systems engineers moving between businesses, since it will be possible to continue development of structured careers, capitalizing on the assessment activity towards and beyond the SEP accreditation.
INCOSE has recognized these advantages through sponsorship of a recent pilot program in the UK Chapter. Following its success, the UK Chapter is currently planning a formal roll out of competence-based CSEP for UK-based members. This will be monitored closely by INCOSE with the potential of offering it more generally as an alternative submission approach in due course.
List of Acronyms Used in this Paper
Acronym Explanation
ASEP Associated Systems Engineering Professional
CAG (INCOSE) Certification Advisory Group
CAR Certification Application Reviewer
CIPD Chartered Institute of Personnel Development
CSEP Certified Systems Engineering Professional
ESEP Expert Systems Engineering Professional
EU European Union
HR Human Resources
INCOSE International Council of Systems Engineering
INCOSE UK United Kingdom Chapter of INCOSE
MoD (UK) Ministry of Defense
SEP Systems Engineering Professional
UK United Kingdom
Acknowledgements
The author would like to thank Professor Doug Cowper who helped develop some of the original ideas used as the basis for this article as part of the preparation and execution of the Competence-based CSEP pilot for INCOSE.
References
[Ref 1, AgeUK]. What is the Equality Act?
https://www.ageuk.org.uk/information-advice/work-learning/discrimination-rights/the-equality-act
[Ref 2, CIPD]. Chartered Institute of Personnel Development. Competency factsheet. https://www.cipd.co.uk/knowledge/fundamentals/people/performance/competency-factsheet#6379 .
[Ref 3, INCOSE]. Certification Program History
https://www.incose.org/certification/CertHistory
[Ref 4, INCOSE]. Current SEP Listing (last updated 1 Jan 2018)
https://www.incose.org/certification [18]
[Ref 5, INCOSE]. Which Certification is Right for Me?
https://www.incose.org/certification/CertWhichOne
[Ref 6, INCOSE]. Educational Background
https://www.incose.org/systems-engineering-certification/certification-faqs
[Ref 7, INCOSE UK CF]. INCOSE UK Systems Engineering Competency Framework and Guide. INCOSE UK Ltd., 2010
[Ref 8, INCOSE SEH]. INCOSE Systems Engineering Handbook, A Guide for System Life Cycle Processes and Activities (Fourth Edition). INCOSE-TP-2003-002-03. Wiley, 2015
[Ref 9, OECD]. OED Employment Outlook (2017)
https://data.oecd.org/emp/part-time-employment-rate.htm
[Ref 10, ONS]. Office for National Statistics. UK Labor Market: Jan 2017
[Ref 11, SHRH]. Society for Human Resource Hiring Competencies Hold the key to better hiring (Jan 2015)
https://www.shrm.org/hr-today/news/hr-magazine/pages/0315-competencies-hiring.aspx
[Ref 12, INCOSE CF]. INCOSE Systems Engineering Competency Framework, INCOSE-TP-2018-002-01.0, INCOSE, 2018.
Note from the Editor-in-Chief Robert Halligan: I would like to share publicly my thanks to Ian Presland for his outstanding article. PPI’s vision for the future is a world in which every engineer is a systems engineer, practicing engineering using systems engineering principles and methods. A 2012 study showed that this approach was then, already, equally prevalent in industry. We believe that a systems engineering professional certification well supports the inevitable and desirable evolution of engineering practice in this direction.
About the Author
Ian Presland is a Chartered Engineer, Fellow of the Institution of Engineering and Technology, Member of the British Computer Society and INCOSE-accredited Expert Systems Engineering Professional (ESEP) with over 35 years’ experience working across many domains.
Until recently he was a member of the nine-person INCOSE Certification Advisory Group which sets the standard and examination for Certification of Systems Engineering Professionals worldwide. He is currently also Director of Professional Development for INCOSE UK; a position he has held since 2012.
In 2015, after many years running the engineering part of a successful multinational training business for Thales UK, Ian left to establish his own independent systems engineering consultancy. His company, Charterhouse Systems Limited, now provides mentoring, training, and consultancy to a wide variety of clients globally.
In 2017 Ian received an Outstanding Service Award from INCOSE for his work linking Competencies and INCOSE Certification, and for leading Systems Engineering Professionalization within the INCOSE UK Chapter.
2.2 Enterprise System Engineering
Applying Enterprise and Architecture in the Practice of Enterprise Architecture
by
Marc H Gewertz
President, EIM Consultants LLC
Email: marc.gewertz@eimconsultants.com
Copyright © 2018 by Marc H Gewertz. All rights reserved.
Abstract
There is much confusion across business, government, and non-profit organizations as to exactly what the differences are between the business practices of Enterprise Architecture, Business Architecture, and IT Architecture. Most of this confusion is due to an overlap of interests, and many differences in terminology between architects, managers, and executives, especially when their activities are coupled with external organizations, customers, and stakeholders with different interests and needs, typical of today’s business environment. Through the lens of a systems perspective of an enterprise in a start-up environment, the basic and fundamental capabilities are systematically differentiated and defined, including the roles and responsibilities for architecting and managing each capability.
Introduction
An expected key value in employing Enterprise Architecture (EA) practices is to gain the ability to manage and control the complexity of an enterprise and its capabilities. Instead, due to the rampant misunderstanding and miscommunication of the practice of EA, the actual ability to manage and control the complexity while in a state of confusion, further complicates the complexity, with an overall outcome devaluing the practices.
Complicating Complexity
The overwhelming majority usage of EA practices is to align business strategy with information technology (IT) efforts. There is much ‘business and IT-related efforts’ to be seen, but there is not much ‘enterprise-related efforts’ in the view, other than aligning business and IT to the mission of the enterprise. Nor, in terms of usage of EA practices, is there much use of EA in ‘architecting’ the enterprise-as-a-whole, but rather, most use of EA focuses on implementing a business and an IT architecture with process and information split between them and partially addressed. Generally, in the use of EA practices, there is also no
‘upfront engineering’ in the form of determining, developing, and managing the needs of the stakeholders in the enterprise, the enterprise requirements, nor the architecture of the enterprise-as-a-whole, before developing the architectures of the parts-of-the-whole.
Ross, Weill, and Robertson for example, have addressed some of these issues, addressing the ‘practicing’, but none the less, the practicing is limited to the application of enterprise architecture in developing a foundation for Business and IT capabilities aligned with strategy.[1]
When it comes to execution, issues in the execution happen because EA frameworks were developed to assist practitioners, but each framework is specific to a domain of architectural knowledge and skills, doing little to nothing to help a team of different architectural domains-of-knowledge understand the roles and responsibilities of each of the domains-of-knowledge.
There have been many publications addressing the need for guidance in understanding and communicating the practice of EA as a practice, and the way the practice fits into a business transformation, but there have been no publications addressing the differences in domains-of-knowledge, skills, and abilities. There are no writings addressing who does what in the utilization of the practice of EA in a business transformation program, project, or initiative. In other words, nothing that addresses ‘the way people work together’ when individually ‘they practice what they do’.
Dr. Scott Bernard, for example, has addressed the issue that books on EA have been oriented towards the experienced practitioner, not specifically oriented towards a person with little to no previous exposure learning the subject.[2] He provides references to related academic research, industry best practices, and observations about potential future practices and the direction of the emerging profession. But even this outstanding attempt to simplify the complexity of the practice, does not address responsibilities by the differences in domains-of-knowledge, skills, and abilities.
Marc Lankhorst, as another example, has provided a work-based view of EA, by looking at modeling, communication, and analysis in a general way applicable to practicing in different business-domains, but still does not address responsibilities by the differences in domains-of-knowledge, skills, and abilities.[3] It does not address the ways work is divided up by skill-sets, nor the means by which the skill-sets work together towards achieving their common goal, over all the individual work to be done.
To compound an already confusing situation, some practitioners may have multiple domains-of-knowledge, may only partially fill a domain-of-knowledge, and/or practice various combinations of full and partial domain-specific practices. For example, enterprise architects (EAs) focus on governance, enterprise business architects (EBAs) focus on strategy and operations, and enterprise IT architects (EITAs) focus on IT. Compounding confusion is reinforced through industry “EA” certifications, all certifications being unique and specific to a domain-of knowledge, domains of which are not acknowledged.
The lack of frameworks distinguishing roles and responsibilities by domain-of-knowledge, and therefore the associated skill-set, has led to much confusion across business, government and non-profit organizations as to exactly what the differences are between the business practices of Enterprise Architecture, Business Architecture, and IT Architecture. This has further led to confusion over responsibilities for Process and Information Architecture and a lack of knowing exactly where the System Architect and Service Architect fit in the overall business transformation efforts. All leading to situations where the wrong skills work important tasks or important tasks are missed.
Much of the confusion is due to the combination of organization-specific differences, compounded by the overlap of interests and many differences in terminology between interacting architects, managers, and executives over many domains of knowledge, skills, and abilities. This especially happens when their activities are coupled with external organizations, customers, and stakeholders with different terminology, interests, and needs, a common working environment in today’s marketplace, driven by preferences to outsource services and the growing availability of options in doing so.
EA Frameworks and Complexity
EA Frameworks are complex implementations of the basics and fundamentals of architectural design. They are specific tools for specific practitioners, established without ever defining the basics and fundamentals. From the holistic perspective of a business transformation, frameworks do little to define the roles and responsibilities of practitioners with different domains-of-knowledge, skill-sets, goals, and objectives. Instead, the frameworks are confusing the situation and driving distaste for the use of the frameworks, rather than providing an understanding of the connections and relationships between the different frameworks and the differences in the practitioners who use them.
It is rather ironic that EA practices are employed to fix the issues with organic development of capabilities, when EA frameworks were organically developed around rapidly growing business needs for IT.
Organization-specific enterprise-level frameworks do exist, for example, FEAF, DODAF, and MODAF, but they are specific to their owning organizations, applying only to the government-based, acquisition-type of business performed within, and the suppliers of these very specific organizations.[4][5][6] Additionally, these ‘government-type frameworks’ are also very large, complex implementations of specific practices. They are fantastic pieces of amazingly thorough and integrated work, absolutely geared towards the most experienced practitioner. Practitioners with the time, money, energy, and will to ‘absorb and apply’ what seems to be an endless amount of framework definition, specified in detail down to the lowest levels of detail.
Except for the Zachman Architecture Framework (ZAF), all ‘standard-type frameworks’ begin in practitioner-specific implementations, in top-down approaches that proceed at architecting the architectures of the elements of the enterprise without addressing the architecture of the enterprise.
ZAF is practitioner-neutral, more than capable of addressing the architecture of the enterprise in a top-down approach beginning at the top.[7] However, it is too primitive, requiring the user to have a considerable amount of know how to apply the interrogatives in specific situations of complex, enterprise-related application. ZAF is a great starting point for those that already know how.
Traditionally, an enterprise architecture is considered to be just a business and an IT architecture. There is no framework defining the enterprise-as-a-whole, nor defining the integration of the parts which form this undefined whole.
Traditionally, the practice of EA has been used to architect IT for business needs. This limited use of the practice of EA tends to ignore other architectural areas, effectively equating the terms “business” and “enterprise” and subordinating IT.
For example, BIZBOK is an implementation of EA serving the needs of business architecture, and like-wise, TOGAF serves IT architecture, and NIST 500-167 Section 7 serves information architecture, each framework overlapping the views of different domains-of-knowledge, without regard to domain-of-knowledge.[8][9][10] Traditionally, EA begins determining business capabilities needed, gaps and strategies, handed down to and ending with IT capabilities being deployed. Where the other architects fit in EA is not clear.
Traditionally, the business architecture is basically everything that is not IT, except for process and information, which gets complex as they are partially present in both the business and IT architectures. The way the business and IT architectures relate to the architecting of mission-related capabilities and technologies other than IT, is not clearly covered, yet the mission of the enterprise is to provide capabilities to customers in the form of offerings, and very often non-IT technologies and offerings are strategic capabilities with interconnections and interdependencies with the architecting of the business and IT capabilities. The traditional practice of EA is silent on supporting the purpose for the enterprise, the reason why the enterprise exists.
Nothing clearly establishes the relationships between the frameworks. Each framework contains topics which overlap frameworks in different ways, without breakdown by skill-set, effectively creating a super-architect role, with the skillsets and knowledge of all architectural domains, and the ability to accomplish anything and everything. One set of all-inclusive responsibilities which no one person has all the multiple skill-sets it requires to perform, as each skill-set involves a college degree and ten years of working experience in the associated domain-of-knowledge.
The use of the term “framework” itself has been an issue, as it implies a structuring of the elements of the framework, yet none of the ‘works’ are graphically similar, and all lack the ontological structure needed for their ‘framing’ to be considered ‘structured’.
Frameworks do not consider the state of what should-be, along the path to the desired to-be. In practice, business transformations happen over long periods of time where the work products produced mature through the combination of stakeholder review and feedback processes and reiterative development processes. Understanding and communicating the acceptability of work products at various points in time through their development is critical to efficiently and effectively producing the work products and realizing the capabilities needed.
Summing up the issues, frameworks do very little to help a team of various architects work together to do their jobs. Frameworks do not address who does what in getting specific jobs accomplished.
EA Terminology & Complications
Complexity is compounded by the lack of EA-specific basic terminology. Industry standards such as ISO/IEC/IEEE 42010:2011 exist, but not in the context of people and technology systems working together as a socio-technical system.[11]
Terms are used freely out of context in communications, confusing the understanding of the concepts being described. Consider, the term “organization”. Does the statement, “the organization has capabilities” refer to a ‘department of people reporting to a manager’, or ‘a collection of tools and materials arranged around a task?
Furthermore, using terms independent of whether they are in context to organizational definition or functional application causes additional confusion. Consider, the term “process”. Does the statement, “the enterprise has processes” refer to ‘procedures, practices, and instructions’, or ‘people and machines performing tasks’?
Complexity is further compounded by the overriding use of organization-specific terms and needs for industry products and services which support the practice of EA. This ‘unorganized effort’ to service the industry results in an ‘industrialized environment’, where the use of marketing terminology and buzzwords abound. This complexity is further compounded by the complexity of a work environment where anyone can be titled anything, without relation to specific knowledge, experience, skills, abilities or responsibilities. Complexity is further compounded by the resulting onslaught of software tools, each of which in their own way, define, the practice in a different way, the conglomerate use of tools only having the result of misleading the way in knowing how to practice EA. None of this is helped by practitioner certifications preceding their knowledge of ‘actually’ knowing how to apply their skills and abilities.
All the variations and deviations are what leads to the miscommunication and misunderstanding of the ‘who’s-what’s-and-when’s’ of ‘actually’ practicing EA.
Rebeginning With Fundamentals & Basics
The practice of EA began, and organically developed, as a collection of autonomous, practitioner-specific, domain-of-knowledge-based implementations of the practice of EA. Each domain-of-knowledge-based practitioner systematically develops the architecture of an element of an undefined higher-order architecture, the architecture of the enterprise.
As a result, from the perspective of systems engineering practices, the typical business transformation, in other words, the typical enterprise system development, begins with the design of the business, information, and IT architectures. But these efforts are often based on a set of incomplete and partial management analysis and planning efforts, an inadequate identification of the needs of the stakeholders of the enterprise, and an insufficient specification and management of requirements of the enterprise. In other words, business transformations often begin as ‘half-baked’ concepts, neither enabled nor assured by the preliminary architectural design and management efforts needed at the enterprise level to sufficiently validate and support it, within the expected range of probability for success, and within an acceptable level of risk to the enterprise, its resources and environments.
Therefore, not unexpectedly, as a result of the ‘bad practices’ being practiced, the practice of EA is currently in a state of ‘dis’. Executives are dissatisfied with EA efforts promising successful business transformation. Managers with responsibilities for transformation are disenchanted with EA. Many are blaming enterprise architects for not delivering that which is expected. Enterprise architects are disgusted with being blamed for ‘higher-order issues’ beyond their control, outside the scope and applicability of their responsibilities. Resolving the issue starts with an understanding and communication of the differences between Enterprise Architecture (EA) and a Business Transformation (a.k.a, an EA program, project, or initiative).
A business transformation is a program, project, or other improvement initiative that an enterprise takes to transform its mission, itself, and/or its capabilities. In a business transformation, the practice of EA is employed, in other words, making a business transformation an EA-based initiative, the point being that the practice of EA is not an EA initiative but rather that an EA initiative employs the practice of EA.
EA is the practice of a field of expertise spanning multiple domains-of-knowledge, commonly used for designing and developing capabilities. Technically speaking, capabilities are socio-technical systems, referred to as “business systems”, realized by a ‘working’ set of people, processes, information, technologies, and other resources. The practitioners of EA are enterprise architects (EAs). EAs focus on the design of governance of the enterprise, addressing the management and control of the socio-technical elements of capabilities, capabilities related to multiple domains-of-knowledge, “multiple” being the key word associated with the complexity of the practice and the ability of the practitioner.
Although a business transformation is an “EA Initiative”, in respect to itself, the work of enterprise architects is not the practice of transforming the business through an EA Initiative. Transforming the business through an EA Initiative requires the expertise of many executive, managerial, and architectural domains-of-knowledge, each practicing their specific domain-of-knowledge-based skill sets within the overall Practice of Business Transformation.
In comparison, in the practice of systems engineering, a system architect role is only one of many systems engineering roles, requiring other systems engineering roles to accomplish the overall goal of delivering a working system to the customer or user. For example, a system integration and test engineer, another systems engineering role, is responsible for integrating the elements of the systems and verifying the integration. The skill-sets of the system architect and the integration and test engineer over-lap, but for the most part they differ, two specific jobs with specific goals, requiring two specific skill-sets seldom found in one individual.
There are many tasks in the development of the system, where the individual tasks of the two roles involve working the ‘same thing’, and it is not intuitive of the ‘thing’, as to where the responsibilities over it differ. A perfect example in systems engineering is knowing which role is responsible for the requirements, the verification, and the traceability tasks associated with the “Requirements Verification Traceability Matrix” (the ‘thing’) in the over task of system verification. In systems engineering, the systems engineering roles know successful projects happen only when all roles know who is responsible for doing what tasks in the development of the system.
Likewise, in the practice of Enterprise Engineering, successful business transformations happen only when everybody in all roles knows who is responsible for doing what tasks in the EA Initiative. Turning business transformation problems around requires everybody knowing who and what is needed in terms of roles and responsibilities and the required skills and abilities. EA frameworks are silent in this regard and only serve to further confuse the issue.
After years of practice, there is still no ‘standard view’ of the practice of EA which shows the practice-as-a-whole. Along with the lack of a view which shows the various domain-of-knowledge-based practices (the parts) and the relationships between the various practices, the practitioners and stakeholders in EA have nothing better to use at understanding and communicating the practice of EA during a business transformation than doing it through the confusion of multiple independent frameworks which begin as complex implementations which have lost the connections to the basic and fundamental concepts.
However, through the lens of a systems perspective of an enterprise, in a start-up environment, the basic and fundamental capabilities can be identified and logically and systematically differentiated and defined, the application of systems engineering and management practices to EA, leading to a clear understanding and communication of roles and responsibilities for architecting and managing each capability.
From the perspective of being in the outside environment looking inward at the whole enterprise and its elements, an “enterprise” is a socio-technical system, a living system of business systems. Business systems are referred to as “capabilities”, collections of people and technology systems, working with information, tools, and other resources.
A “startup enterprise”, like any developing system, has a ‘life’ that develops from an idea to realize the business of the enterprise. Everything realized is realized over time and progressively matures in stages. As with all systems, the resultant enterprise is sustained over its life by maintenance, improvement, changes, and transformations.
The enterprise’s self-sustaining life begins with an idea/vision and a motivation to create and continually change to serve the purpose of offering a value-adding system or service needed by a customer, a mission with the goal of supplying value-added ability to satisfy needed demand.
Operating in the external environment drives needs for capabilities to provide offerings. External needs drive a functionality to realize internal capabilities to accomplish what the enterprise is capable of and in turn what the enterprise can do. In other words, external needs drive the need for the internal capabilities to support the offerings to satisfy the external customer.
Represented within the conceptual context of the working environment, with mission and goals driving the focus of interest within, starting at the beginning of life, and following the basic and fundamental sequential needs, the basic and fundamental capabilities can be differentiated based on what the capabilities are intended to do (their functionality) and the purpose they serve (their goal). However, although architecting a system is a top-down task, being successful requires an understanding and communication of the elements at the bottom of the ‘system hierarchy’. Therefore, in order to better understand this top-down view of basic and fundamental needs driving requirements, we must first begin at the bottom of the view of basic and fundamental needs, and build this understanding up, from the understanding of the lowest level elements, the technology systems the people in the business systems use.
Systems and Technology
Understanding and communicating the complexity of business systems begins with first understanding systems in general, and the mechanistic nature of technology systems, as the probabilistic nature of people, and what they actually do when interfacing with the technology system, actually determines what becomes the probabilistic output of the mechanistic technology system used within the higher-order business system.
To form business systems, technology systems are deployed into operations involving people, information, and technology. Understanding the complexity of business systems begins with understanding the complexity of technology systems before adding any probabilistic elements into the situation.
Applying top-down enterprise-level system engineering methods, through increasing specifics of needs and requirements, begins with the architecting of the enterprise, where the bottom-up understanding of the enterprise is first considered as a system, in the classical meaning, and step by step extrapolate the system through increasing specifics of purpose and usage, to arrive at the architectural description of a socio-technical system and the lowest level of the specifics of the abilities needed.
A System
To begin with the basics and fundamentals which continuously apply throughout the details of the specifics, as shown in Figure 1, regardless of the specifics of the system, to be a system, the system must have a boundary which establishes its internal and external environments. Things internal to the system are things being of the system, and things outside the system being things which interact with the (open) system.
Within their boundaries all systems have relevance by their existence, defined by their structure, which functions to serve the purpose for the existence of the system.
Figure 1: System (Open System)
All systems are composed of a whole, which has parts (a.k.a, elements). Each part has relationships with other parts, and relationships with the whole. All systems have a command and control functionality which understands and communicates with the parts of the system to enable and assure the system and parts behave as desired.
Basically, and fundamentally, all systems work by taking inputs of matter, energy and/or information to the system, which are transformed by the parts of the system, to produce outputs of matter, energy and/or information from the system, for the ultimate purpose of sustaining the system, for the life of the system, both internally, and within the environment surrounding the system.
A Technology System
Complexity increases by placing a system, as shown in Figure 2, into the context of being a technology system, in its external environment, where the application of the technology’s related functionality, in serving its purpose, is intended to be a value-adding sustainable situation over the life of the system. Consider, a management information system.
Figure 2: Technology System (Value-Adding System)
Inputs of value to the system, are transformed by the parts of the system, into outputs of higher value, serving the value-adding function-related purpose of the technology, exchanging lower value for higher value to the external environment, but also in so doing, maintaining, or increasing the value of its internal environment.
In other words, in doing what the system does in the external environment, the system structure needs to be able to internally survive in its functioning to serve its purpose. For example, in processing management information, the management information system must be able to handle the management information without malfunction resultant of the processing.
Two Technology Systems
As shown in Figure 3, complexity continues to increase by placing the technology system into the more specific context of being a management information system with a management-based, information-related, function, serving a management-based, information-related purpose, operating along with a second system, an IT services system, with an IT-based, services-related function, serving an IT-based, services-related purpose.
Figure 3: Two Technology Systems
In this situation the two systems are interconnected with inputs and outputs between the two systems, with inputs to the management information system, transformed into outputs from the IT services system. Each system operates within a separate internal environment, each system works within a common external environment. Each system serves its purpose independent of a purpose for connecting the two systems together.
The problem with this situation is, the ability of each system, to communicate with, understand and survive the other system, and serve its intended purpose, cannot be fully determined, until it is first determined, what higher-value purpose the combination of the two systems, is intended to accomplish.
A Technology System of Systems (SoS)To determine the abilities of two combined systems, the two systems need to be described within the context of the higher order purpose, and not left simply within the context of two systems being combined. To practitioners of systems engineering, this may seem like a rather parochial statement, however, in the development and operation of higher-order business systems, the parochialism is quickly lost in the complexity of combining business systems.
The description of the combination must be described within the boundaries, relevance, composition, and governed behavior of the higher order system. In other words, the two systems need to be addressed as elements within a system, a situation known as a “System of Systems” (SoS), a complex combination of what are essentially ‘dependently-independent’ systems, working ‘individually-together’ in a non-hierarchical, oxymoronic situation of powerful ‘autonomous-collaboration’, as described in the INCOSE System of Systems Primer.[12]
As shown in Figure 4, by placing the two technology systems into the context of a managed backup and recovery functionality, a backup and recovery SoS, is formed, with lower order systems of specific purpose, placed within a specific higher-order system, with a specific higher-order purpose, beyond the purposes for the lower-order systems. Two systems, of different purposes, operating together, for a common purpose, forming one higher-value system of increased ability and value, and along with the benefits, increased complexity and difficulties in determining, and therefore predicting, the expected behavior.
Figure 4: Technology System of Systems
Socio-Technical Systems
The involvement of people and technology systems within business systems leads to probabilistic outcomes as previously mentioned. Even the ‘hard connections’ between technology systems are ‘softened’ by the existence of the probability of the installer of the interconnections making errors in ‘connecting’ what are otherwise deterministic connections. Certainly, mechanistic connections can vary, but the understanding of the variation is deterministic and the connections can be designed to operate within the known design limits. But even tested and certified technology systems can lead to probabilistic outcomes simply because the people who interface with the system (users/operators) making errors in inputting the inputs to, or in receiving the outputs from, the technology system, and the inability to preclude every possible error from negatively effecting the business system has unknown limits.
Peter Checkland addresses socio-technical systems using his “soft systems methodology”, applying systems thinking to the understanding and communication of socio-technical systems.[13]
Brian Sauser and John Boardman expanded upon Checkland’s work by taking a systems engineering view of systems thinking applied to socio-technical systems.[14] They describe a systems-based response to difficult problems and situations by using pragmatic mechanisms, addressing ‘togetherness’ and the other special characteristics of socio-technical systems, complexity and paradoxes.
The complexity of adding probability into the ‘complexity and difficulty equation’ is further compounded by the need for cross-functional functionality and satisfaction of dependencies between the probabilistic systems, which is then further compounded by the complexity of placing these probabilistic business systems within higher order probabilistic applications forming probabilistic business systems of probabilistic business systems, surely a wickedness of wickednesses.
Furthermore, it is not hard for even a small enterprise to fall victim to these difficulties by building business systems around today’s rapidly changing, cross-operational technologies, as will be demonstrated in the following sections by extrapolating a business system through increasing specifics of purpose and usage.
Cross-System Communication and Understanding
The complexity of a socio-technical system of socio-technical systems is mainly driven by the need for the systems to cross-communicate and understand the cross-communications.
For different systems of different purposes to communicate with and understand each other, the specifics of the interconnections and interfaces between the systems must be systematically addressed in order for the systems to interconnect and function (work) as desired, with value, to all the systems and the environments in which they operate.
Various application and domain specific interfaces and methods of interconnection are used as appropriate. Interconnections are differentiated by their form, their function, and the purpose they serve, and to address the characteristics, levels, and physical ability of the interconnections to conduct communications.
The point being, the expected behavior of a technology system or SoS, can be pre-determined through its design. But that is not the case once people are added to the equation. As people by nature are adaptive, and their adaptive ways tend to have unintended and unforeseen influences on what are otherwise considered to be deterministic means, probably resulting in unintended and unforeseen outcomes.
Unlike technology systems, business systems are under a constant state of change due to never-ending competition, organizational changes, technological advancements, and business process improvements. Connectivity and dependency between business systems, combined with the need for change, drives the need for communication and understanding between the changing business systems. Due to the interconnections and interdependencies between business systems, additions or changes to elements of a capability (a business system) must holistically consider other elements of the capability, and other capabilities (other business systems), and their elements.
For example, in the situation of implementing a new enterprise resource planning (ERP) system, a typical enterprise-wide improvement initiative taken by many enterprises, additions of, or changes to, the workflow element of the organization’s standard process driven by the workflow element of the ERP system, must be managed and controlled to consider affects to policy and procedure as shown in Figure 5. The need to take these considerations are usually well known within the process domain-of-knowledge but are much less known by the other domains, a specific practice of tunnel vision commonly known as “leaving it to the process people to take care of”.
Figure 5: Connecting the Process Dots
The issue is that there can be effects on other elements that are not as ‘directly’ known, and without a holistic view of the situation, these elements may never be considered until the error is inadvertently discovered when the change to one element breaks another unforeseen element, a possible outcome that should have been known and identified and therefore avoided.
The point of this all being that there is a critical need to take all the considerations needed, so all needed considerations must be identified. In a complex socio-technical system, the only way to enable and assure this, is through the early and continued involvement of all domains and their knowledge, until each domain determines, through its involvement and knowledge, that their involvement is not, or no longer needed for the specific situation, a specific practice of holism commonly known as “inviting everybody to the table”.
For example, “process people” know the limits of governance set the policy requirements on the procedures used by the roles in executing compliant process workflow. For this reason, the expertise of managers and architects from the process domain-of-knowledge needs to be involved in changes and additions to workflow to assure the new workflow is capable of remaining compliant with policies and the associated governance requirements from which the policies are derived.
Governance requirements are typically a complex combination of over-lapping requirements including, as an example, business-specified, regulatory, industry standards and contractual requirements, requirements whose identification and specification is the responsibility of the enterprise manager and architect roles. To avoid any potential issues with maintaining compliance to enterprise requirements within workflow, additions and changes should therefore involve the roles associated with enterprise management and architecture as the details are beyond the scope of the roles associated with process management and architecture.
Furthermore, improvement of process workflow must also consider effects on the offering of system solutions and service solutions, almost always driving the need for involvement of the system and service managers and architects.
More specifically, workflow and the offering of solutions also has relationships with, and dependencies on operations of the business. Changes therefore must also holistically consider, the process-related elements of business operations, for example, effects of the change of process workflow on the value stream element of business operations, driving the possible need for involvement of the program and business managers, architects and analysts.
As shown in Figure 6, workflow also has relationships with all elements of insight, driving the possible need for involvement of data, information, and knowledge managers and architects, and with the insight-related and process-related elements of IT information utilization, possibly requiring the involvement of the IT managers and architects. These related elements additionally have relationships with the over-arching needs for the integration of capabilities and resources, and compliance with requirements and regulations imposed on all elements of the enterprise, once again driving a need for involvement of enterprise managers and architects.
Figure 6: Holistically Connecting the Dots
In addition, there are 2nd degree of separation functionalities reaching-out, for example, to business talent, for example, by possibly driving an associated need for training, and again, further involvement of the business managers and architects.
The details of talent training, in turn, are related to the details of process roles. Therefore, changes and additions to training reach back to the process workflow, where this path of interdependencies first began, from there reaching back out to procedure and policy, possibly reaching further back to driving changes and additions to governance, and possibly beyond, into issues with other elements not readily ‘seen’.
In practice, holistically considering other elements involved in the addition of, or change to, a capability, and other capabilities, and their elements, means there are working interdependencies for work products and other information to be communicated between the team members of the business transformation. Work product needs form time-dependent relationships in the flow of cross-functional work which must be known by all the roles involved in the work.
The problem is, the lower order a system function is in the SoS, the more system boundaries exist between it and other system functions, with more communication and understanding losses at each interface. This results in more disconnects and interdependencies with other systems of the SoS, and the less its system function serves the higher order needs of the other system functions.
In other words, the more disconnected, the less the roles will communicate and exchange information and work products, and instead, will ignore the issue, stop work, determine a work around, or otherwise deal with the impact to their work, adapting to working with insufficient inputs and outputs, all possibilities needing to be identified, analyzed, understood, planned, mitigated, communicated, and closely managed and controlled.
The need for all systems to serve the common mission of the enterprise demands cross-functional systems be identified, understood, aligned, balanced, managed, controlled, and communicated.
Needs for agility and affordability require that cross-functional activities be coordinated, cooperative, and synchronized, further increasing needs for cross-functional communication, understanding, and integration.
Cross-functional dependencies must be addressed to enable and assure the functionality of all dependent capabilities.
Managing and controlling cross-functional dependencies is therefore critical to managing and controlling integrated activities, and in enabling and assuring proper and thorough consideration of changes to capabilities and the resultant impacts and needs on resources and other capabilities.
Communication and understanding between roles is therefore a very critical socio-technical characteristic of business systems needing to be addressed in the design, development, deployment and operations of business systems.
A Business System (A Socio-Technical System)
Because of the need for cross-systems functionality and the probabilities involved in satisfying cross-functional dependencies, determining the behavior of a system, when placed into the context of an operating business system (a capability), is difficult, to say the least.
To begin to explore the difficulty, a good example is the highly probabilistic situation of a business system for system development and operations, a capability to develop and/or operate a deterministic technology system as shown in Figure 7. A situation involving systems engineering ‘people’, including systems architects and system managers, the people who lead the development and operations of the technology systems. Always a rather complex situation, requiring the abilities of many different skill-sets and the involvement of many technologies. Worse yet, a situation typically based on technical, time, cost, and quality commitments. The typical situation of “if the wrong things can happen, the wrong things will happen”, if the understanding and communicating of the correct things happening is not completely known, analyzed, planned for, managed, controlled, monitored, and measured by the work of the system manager and system architect.
Figure 7: Business System (Socio-Technical System)
In this case the technology system remains deterministic in its nature, but the development and operation of the technology system are an adaptive business system with a probabilistic nature, as the ‘developing’ and the ‘operating’ of the technology system needs the involvement of a least one person, if not many people, with varying skills and abilities, executing processes, using and producing information and other resources. All these probabilistic things are happening beyond the need for the technology system itself, even when the technology is performing most of the work. Nor is development or operation of the technology system possible or sustainable without a minimum level of these additional resources, regardless of the level of automation.
In this situation shown in Figure 7, there is a business system the goal of which is a business functionality, where the technology system being developed and operated, interacts with a rapidly changing, complex mixture of resources, such as,
- machines, tools and equipment,
- information, materials and other things needed,
- goods, services, and associated work products produced and used, and
- an adaptive workforce of executives, managers and individual contributors, and their adaptable devices, including the responsible system managers and architects and their ever-changing technologies.
All of which may, or may not, be adding value in this situation, as it is a complex situation, not easily, nor reliably determined.
It should be noted, graphically, in this document, the interconnections between the technology system and the other elements of the business system are purposely not shown in Figure 7, for effect, as they are not always known, or dependable, as there is only a probability they will be identified and connected correctly, including the technology to technology connections, whether these connections are ‘wired’ or ‘wireless’. But in practice, all interconnections do exist, the interconnections must be known, understood and communicated.
Obviously, a business system is a situation requiring management and control to be successful, as all business leaders know, as all business leaders have experienced.
Two Business Systems
As with technology systems, as the number of business systems multiply, and interconnectivity and interdependencies grow, so does the complexity, and in the case of business systems, a compounding of probabilities and difficulties occurs.
To begin exploring this, as shown in Figure 8, the system development and operations business system is next placed into the specific context of managed backup and recovery business system, where there is the development and operation of a business system for managing backup and recovery, and the development and operation of a business system for backup and recovery operations.
Figure 8: Two Business Systems
To make the situation more complex, unlike technical systems with dedicated resources within each system, with business systems there is most often sharing of the resources, in this example, the management information system, and potentially, every other resource, most probably including the human resources that may, or may not, be ‘available’ when their need for involvement is required.
Each business system has its own goals. These goals are placed upon the business system by placing goals upon the workforce within the business system. These goals influence the workforce to focus on meeting their individual goals. Without a common goal, just as with technology systems and their function-related purposes, the compatibility of the two business systems properly working together cannot be determined.
A Business System of Systems
Similar to the situation of two technology systems working together, as shown in Figure 9, by placing the two business systems into the higher-order purpose of backup and recovery services, and what the purpose of, and needs for, these backup and recovery services are, the individual business systems can be transformed into a business system of business systems, with IT managers and IT architects individually working together, sharing IT-related resources as needed, for the purpose of meeting their common IT-related goal, providing backup and recovery services.
Figure 9 : Backup & Recovery Services System of Systems
As a second example, as shown in Figure 10, we can place business systems, into the specific context of desktop applications, with a business system for desktop applications management, and another for desktop applications operations. Like backup and recovery, we can place these two business systems into the higher-order IT functionality-related purpose of desktop application services, with IT managers and IT architects and their IT-related resources.
Socio-Technical Complexity
All business systems are SoSs since each system requires an associated management system to command and control it. For example, without a management system with its command and control function-related goal, the system development and operations system shown in Figure 7 will most probably fail in meeting its technical, cost, and/or schedule commitments in working to accomplish its system development and operations function-related goal.
Figure 10: Desktop Applications Services System of Systems
Additionally, the resources within a business system are generally shared across multiple systems. Since all systems have different purposes and goals, sharing of resources needs to be managed and controlled or the conflicting situations are ‘guaranteed’ to be problematic. For example, besides conflicts with workers and other shared resources, conflicts in the operations system extend over to conflicts in the management system as managers ‘move’ between solving conflicts in the operations system they command and control, and participating in the management system of managers in which they are also involved.
As this all adds up to additional business SoSs, with growing conflicts between the SoSs, and between the systems within the SoSs. This dramatically increases complexity, as lower level business systems are combined into higher order business systems of increasing ability and value, at the expense of dramatically increasing the difficulty in communicating, understanding, managing, and controlling.
Therefore, to keep the complexity ‘simple’ within this presentation, all examples of SoSs which follow are limited to two elements per SoS. It should be noted, in reality, there are often many elements in a SoS, dramatically increasing the complexity and difficulty in communicating and understanding, and in managing and controlling, as one can imagine.
A Business SoSoS (SoS2)
Similar to combining business systems into a SoS, two business SoSs can be and often are combined, further increasing ability and value, but at the further expense of increasing complexity and difficulties in communication and understanding, and therefore the need to manage and control an increasingly difficult situation.
For example, as shown in Figure 11, combining backup and recovery services with desktop applications services into the higher-order business-related purpose of desktop computing services, a ‘SoS squared’, a situation of complexity that is typical of an average IT Services Provider.
In this situation, there is a very complex composition of resources and probabilities, with business managers and business architects, their business-related resources, and their probabilities for behaving as expected, dependent on IT resources and probabilities, both of which are further dependent on system-related resources and system-related probabilities, without firm ‘lines of authority’ between the SoSs to be used to manage and control the overall situation (the ‘big picture’) of providing desktop computing services to satisfy customer needs.
In other words, in the drive for an enterprise to increase the ability and value of its capabilities, there is a growing need for the satisfaction of cross-functional dependencies, between a growing collection of increasingly independent people with a decreasing ability and need to satisfy these cross-functional needs.
Figure 11: Business SoSoS (SoS2)
A Business SoSoSoS (SoS3)
Similarly, as shown in Figure 12, it would not be unheard of to combine desktop computing services with database services to form a higher-order company-related system with the purpose of being an enterprise with the mission of providing web services. This is now a ‘SoS cubed’, a level of configurations of business systems, where the people who develop and operate the technology systems which support the higher-level business systems, are beginning to be hidden in the finest details of the depths of the business, with compounding layers of cross-system management and control issues driven by communication and understanding issues between the business systems, leading to disconnects and fallout if not properly managed and controlled.
To recap the path to achieving this rather reasonable level of ability and value typical of an average full-service IT services provider:
- The situation began as a system of two different business systems with two different goals, sharing common resources for a common goal.
- By combining SoSs, the situation transformed to a larger system of six different systems with six complex goals, sharing common resources for a common complex goal.
- By combining SoS2s, the situation transformed to a larger, complex system of seven different complex systems with complex goals, sharing complex common resources for a common very complex goal.
A Business SoSoSoSoS (SoS4)
It is also not totally unheard of to further combine systems for increased ability and value. For example, an eCommerce Provider using its ability to design, develop and operate internal IT capabilities, to provide IT services to external customers, transforming the enterprise to an even higher-order purpose of greater ability and value. But this arrives at a level of complexity where, unless understood, communicated, enabled, managed, controlled, and assured, the business managers and business architects will be disconnected with the system managers and architects, leaving them off the business transformation team, left as a detail to be taken care of by IT managers and IT architects, details to be taken care of too late.
As shown graphically in Figure 13, the lower-order business systems are becoming undiscernible in the ‘big picture’, which is dangerous to the success of the business transformation team as a whole, by excluding the people of the business system which ultimately everyone and every other business system is dependent on. Lower order is not less important!
But an enterprise does not need to be an ‘Internet Giant’, for its business systems to quickly get complex, since business systems are complex, even in the most simple of situations, such as two different business systems, functioning with different purposes, working together, for a common purpose.
In today’s world of a highly interconnected mix of people and technology, in a rapidly changing, cost-reducing, and ability demanding market environment, when it comes to developing and/or operating technology systems for cross-functional business applications, controlling the whole enterprise, and all its socio-technical parts, to achieve acceptable outcomes, for the customer, and the enterprise as a whole, is very challenging.
Degrees of Communication and Understanding
Each business system has people with the common goal of serving the function of the system.
Communication and understanding between the people within the business system is promoted by the focus of the people on meeting the goal. In other words, the people within the business system have a purpose for communicating with and understanding each other.
Unfortunately, because business systems are ‘soft systems’ with ‘soft connections’, where interconnections have probability and the resultant lack of dependability, the goal which promotes communication and understanding between people within the business system, is the same goal which impedes communication and understanding between people of different business systems. In other words, the different goals of different business systems tend to make interdependent business systems operate independently, as each business system prioritizes serving its own function at the expense of not serving the functions of other business systems.
This happens because goals and soft systems create a paradoxical situation. Without goals, organizations do not have purpose, and will lose motivation. With goals, organizations are motivated to lose integration, resulting in loss of functionality. Organizations need goals but the goals drive functional silos. Capabilities need resources but resources drive cross-functional needs.
Furthermore, as everybody does their jobs, the impedance, capacitance, and losses in communication and understanding between different business systems is compounded when higher order business systems are formed from the lower order systems.
Eventually the enterprise reaches the point where the people in the higher order systems have little to no communication or understanding of the people in the lower order systems whose success at the bottom will ultimately determine their success at the top.
This happens because the view everyone sees their work as they do their jobs, is a bottoms-up, inside looking outward view of the enterprise, a view of work where the value of the value stream increases moving forward, with each receiving system adding value and delivering to the next system to add further value.
From this perspective of the enterprise working towards building increased value, in the situation of a large, complex enterprise, typical of many corporations, as shown in Figure 14, the people and goals related to the business systems developing and operating technology systems and services (i.e., the purple elements in the top right corner of the figure) can be 1 to 4 (or more) degrees of separation away from the people and goals related to the business systems the technology systems and services support. In other words, the needs of other managers and architects falsely ‘appears to be’ of ‘lower standing’ to business managers and architects, and this issue grows along with increases in ability and value. In summary, the more ability and value an enterprise has, the more difficult it is to sustain the situation as a whole.
Figure 14: Degrees of Communication & Understanding
In practice, we recognize this separation of people by goals, and the resultant breakdown of communication and understanding, as a “functional silo” when it comes to working and getting the job accomplished. This happens because each collection of people is focused on doing their own jobs and accomplishing their own goals, the jobs and goals of other people of other functions being secondary at best, and generally, if not proactively commanded by management, is ignored until issues of neglect surface. But in the design of a business-wide capability in today’s business world, the situation can be a functional silo to the ‘4th power’ as shown in Figure 14.
The increasing degrees of separation are why the business strategist thinks the architecting of the technology system or service is down in the details of the technical weeds. This is why the typical business strategist considers that technical considerations are not deserving of consideration in the development of strategies, in the architecting of the business, up in the executive office. The result of the compounding of functional silos is often an outcome with IT people ‘stuck’ between the business people who want strategic capabilities, and the products, systems, and services people who do not have the ability to realize the strategic capabilities as desired.
The point is, the development of a technology product, system, or service, for a business-wide purpose, in terms of meeting needs throughout the structure of needs, is a compounding of probabilistic systems, within probabilistic systems, which will most probably be problematic, if the management of the probabilistic systems is not architected into the design of the systems.
In other words, in the development of a socio-technical system actions must be taken to enable and assure that the elements of the socio-technical system are achievable and manageable, within the desired control limits, for the desired length of time, just as in the design of any technology system.
Like technology systems, for different business systems of different purposes/goals to communicate with and understand each other, the specifics of the lines of communication between the systems must be systematically addressed for the systems to interface and work as desired, with value, to all the business systems, to the enterprise-as-a-whole, and to their environments, both internal and external.
Various application and organization specific interfaces and methods of interacting need to be established and used as appropriate. Interactions must be differentiated by organization, the function they serve, and the goals they have. The characteristics, levels, and physical ability of the socio-technical interactions to conduct communications must be addressed.
To summarize, communication and understanding are application and organization-specific. Since the abilities of people working on an EA team, have application and organization-specific difficulties and deficits resultant of the complexity and complications of frameworks and non-standard terminology, the practice of EA has communication and understanding difficulties which must be solved for the practice of EA to function efficiently and effectively.
Business and IT architects have been stuck with frameworks promoting a bottom-up, inside looking outward view of the enterprise, good for implementing an architectural design, but inadequate for performing management analysis and planning tasks supported by the preliminary architectural tasks needed during the early phases of a business transformation. It is not surprising that IT projects often have issues.
The practice of EA needs an application and organization-neutral view of the entire enterprise. A top-down, outside looking inward view of everything. The view the System Architect uses to do upfront, high level design tasks. This is the view that all architects need.
A System of Offerings and Capabilities
Improving the practice of EA begins by the practice acknowledging the existence of the various skill-sets by distinguishing enterprise architecture from business and IT architecture, addressing process and information architecture separately, and to architecturally include the offering of technology system and service development and operation.
Improving the practice of EA continues by differentiating work by goals, roles, and interdependencies between all architects, and all levels of management, including executives, and improving interactions by increasing teamwork, satisfying cross-functional needs, and leveraging the diversity of knowledge in practicing EA, in order to integrate the communities of practitioners.
Specifically, to improve communication and understanding of EA, roles and responsibilities must be differentiated by skill-set, broken down by work and things needed and produced. Cross-functional dependencies must also be known, understood and communicated in terms of what is used and produced, when things are needed, and their expected state at the time of the need.
By looking at an enterprise as a system of capability systems, the basic and fundamental roles and responsibilities can be clearly and logically defined by following the path of needs which defines an enterprise, as shown in Figure 15.
The path of enterprise needs begins with the enterprise itself, with a vision, understanding, and communication of what the enterprise is. An enterprise can be any endeavor, but regardless of what the enterprise specifically is, an enterprise needs a broadly communicated and fully understood mission to give its resources purpose and motivation to accomplish the mission.
An enterprise also needs customers, as an energy source to fuel the motivation for the enterprise to take actions to accomplish the mission, captured in a mission statement of what the enterprise will do to satisfy the customers.
Customers need offerings of products, systems, and services which provide them with the abilities they need and want.
Offerings need capabilities to produce offerings to satisfy the customers. Therefore, the enterprise needs people, process, information, and technology to realize the offerings, and in turn, the ability to satisfy the needs of the customer. This in turn satisfies the needs of the enterprise.
The system works continuously as the needs of the enterprise are aligned to and balanced with the satisfaction of the needs.
As shown in Figure 16, conceptually, the systems-of-interest of the enterprise associated with architectural and managerial roles and responsibilities, interconnections and dependencies are the:
- Enterprise Capability – resources which together systematically function to realize an ability to satisfy a customer-based need.
- Enterprise Management – resources which together systematically function to realize an ability to control the functionality of the capability.
- Enterprise System Manager Role – resources which together systematically function to realize an ability for controlling the functionality of the capability.
- Enterprise System Architecture – resources which together systematically function to realize an ability to describe the capability.
- Enterprise System Architect Role – resources which together systematically function to realize an ability for describing the capability in support of controlling the functionality of the capability.
Figure 16: Enterprise System Concept Diagram
Specifically, as shown in Figure 17, the functionality of each CAPABILITY is controlled by a MANAGEMENT functionality supported by an ARCHITECTURE describing the managed capability.
Figure 17: Enterprise System Overview
The MANAGER ROLE is responsible for managing and controlling the functionality of the capability and for producing the supporting management work products, using the architecture and supporting management work products to support their management responsibilities and activities. The ARCHITECT ROLE is responsible for architecting the concepts, logic, physics and other properties and characteristics of the managed capability and for producing the supporting architecture work products, using the architecture and supporting work products to provide an understanding and communication of the capabilities and resources, and the interconnections and interdependencies between the resources, between the resources and the capabilities, and between the capabilities.
To summarize simply, each capability of the enterprise is managed by a manager and architected by an architect. The next step is to determine what all the capabilities are, so responsibility for the capabilities can be related to the roles.
Since the resources of the systems systematically function together to realize the ability of the system, the functionality of the enterprise must be broken down into the basic and fundamental functionalities of which it is formed in order to determine which roles are responsible for which capabilities.
Because systems can be differentiated by their structure, function, and the purpose they serve, working capability systems (capabilities) can be differentiated by the multiple goals it takes to accomplish their common mission, and the mission-centric functionalities they provide. From this differentiation of functionalities, the associated architectural and managerial roles are identified.
Therefore, as shown in Figure 18, and presented in the sections which follow, beginning at the start of needs for the enterprise-as-a-system, and following the path of needs through the transformation to the satisfaction of the needs, the basic and fundamental systems, serving basic and fundamental functionalities, are sequentially formed, as the need for the system functionalities develop. As presented, this begins with the idea for an enterprise and its offerings, and follows the development of needs through to the delivered offering satisfying the customer need for the offering.
Figure 18: Enterprise Lifecycle
The following sections and examples detail the path through the capability systems. In practice, management capabilities realized by management teams, supported by architecture teams, with their different breakdowns in processes, information, and technologies, within and across capabilities, are each multiple capabilities (multiple people, process, information, and technology) serving different purposes for a common mission. This drives the need for all the different managers and different architects to effectively and systematically function as one cohesive capability, within capabilities and across capabilities.
Ultimately, this drives the need for the practitioners and stakeholders of EA to address their practicing in a business transformation as a practice of practices, rather than treating it as a set of autonomous practices with overlapping interests overseen by an enterprise architecture review board (EARB).
Enterprise Capability System
Considering an enterprise as a system of offerings and capabilities in a start-up environment, as the motivation of an entrepreneur turns into actions to implement their idea for an offering to a customer, a basic and fundamental need forms, for the enterprise to exist, act, and behave as an enterprise.
Over time, the need transforms into an enterprise capability system, a systematic ability to satisfy the need to control the behavior of the enterprise through:
- governance to control resources,
- organization to arrange, order and assign resources,
- integration to bring resources together,
- compliance to verify resources are controlled,
- assurance to independently validate compliance, and
- enterprise management of the elements of the enterprise capability, with the capability interconnected with all other capabilities.
In this way the enterprise capability system serves as the ‘control’ system of the enterprise.
The enterprise manager and enterprise architect are responsible, respectively, for managing and architecting the enterprise capability system.
This is the point at which the ‘simplicity’ of basic and fundamental functional roles definition ends, and the point at which the transformation begins into the complications and complexity resultant of the multiplication of organization-specifics, preferences, and needs.
The specification of roles and responsibilities begins with organizational positions. Positions are locations within an organization’s authority and responsibility hierarchy where people from the workforce are placed. Positions have position titles. Position titles are not standardized, nor will they ever be, needing to be reflective of the specifics of the enterprise.
In their positions the workforce is individually assigned jobs. Jobs assign the workforce to roles. The jobs have job titles, and similar to position titles, job titles are not standardized either, nor will they ever be, needing to be reflective of the specifics of the enterprise, positions and jobs. In some cases, the position title and job title may be same, in others they may be similar.
Therefore, in practice, there are many variations in role assignments and position and job titles. The following paragraphs and examples will relate the more common organization-specific variations in the enterprise management and architecture roles.
To satisfy specific organizational needs the responsibilities of the enterprise manager/architect role are specified through organization-specific job assignments.
Depending on the needs and abilities of the enterprise, the role can be filled by one job or many jobs, with responsibilities for the elements of the enterprise capability system allocated accordingly.
For example, an organization-specific job focused on enterprise management/architecture supported by managers/architects in a governance and compliance job, in an organization and integration job, and in an independent assurance job is shown in Table 1.
Table 1: Enterprise Role by Functional Job Matrix
The “need to control the behavior of the enterprise”, drives the need for enterprise managers and architects to oversee the managing and architecting of the offerings and capabilities in relation to their governance, organization, integration, compliance, assurance, and management.
To address the organizational ‘work load’ and other organization-specific needs of large organizations, there are often specialty jobs focused within enterprise management/architecture and others focused on enterprise-level oversight of specific offerings and capabilities.
For example, an enterprise business management/architecture job and enterprise IT management/architecture job overseeing the governance, organization, integration, compliance, assurance, and management of the business and IT capabilities, and other enterprise-level oversight jobs responsible for offerings and capabilities is shown in Table 2.
Table 2: Capability Oversight Role by Functional Job Matrix
When the enterprise manager/architect role is supported by sub-roles and oversight roles in enterprise management/architecture, the enterprise manager/architect role enables and assures these supporting roles are governed, organized, integrated, compliant, assured, and managed in their efforts and in the overall enterprise management and architecture effort, so their management and architectures properly integrate with other management/architectures within and outside the enterprise management/architecture.
In practice, the responsibilities of the enterprise manager role are assigned through organizational job positions with various titles.
Examples include “Entrepreneur”, “Owner”, and “President”. Oversight responsibilities are also allocated, for example, to a “Vice President” or “Director”, or as shown in Table 3, through chief executive positions with the title of “CEO”, “CIO”, “CTO” “COO”, “CFO”, and other executive jobs including oversight of the enterprise and “Chief” positions by members of the “Executive Board” or “Board of Directors”.
Table 3: Managerial Oversight Role by Organizational Title Matrix
In practice, the responsibilities of the enterprise architect role are also filled through organizational positions.
Overwhelmingly, these positions have the title of “Enterprise Architect”. But the responsibilities vary greatly across the community of practitioners, and sometimes the organizational job may not even include the functional role responsibilities of the enterprise architect, simply using the title assigned to an IT job with IT architect role responsibilities without addressing socio-technical considerations, for example.
Some practitioners are focused on enterprise management/architecture applied to business and/or IT management/architecture (e.g., “Enterprise IT Manager” or “Enterprise Business Architect”), while others remain focused within enterprise management/architecture, working with a business and/or IT manager/architect role.
Enterprise architect role responsibilities are in some cases fully or partially allocated through leadership positions with the title of “Chief Architect”, “Chief Technology Architect”, “Chief Enterprise Architect” and “Chief Strategist as shown in Table 4.
It should be noted in practice, the enterprise management/architect role is often fully or partially combined with other managerial/architectural roles to provide an organizationally needed job (a ‘specialty’) to address the special organization-specific needs and limitations of the organization. Examples include “Enterprise Business Architect”, “Enterprise Process Manager”, “Enterprise Knowledge Manager” and “Enterprise IT Architect”.
Table 4: Architectural Oversight Role by Organizational Title Matrix
Regarding responsibilities within and outside the enterprise capability, the allocation of responsibilities to the enterprise management/architecture roles demand attention to detail to ensure all functional role responsibilities are accounted for when it comes to understanding and communicating responsibilities through organizational jobs, titles, and nomenclatures, as some organizations may prefer to do and is often the case. The issue is the variations in the allocations of responsibilities over the variations in roles assignments and job titles has the risk of inadvertently missing the assignment of functional role responsibilities.
Therefore, enterprise management and architecture plans, procedures, and practices should specify responsibilities for the enterprise manager/architect role and supporting roles through a functional role responsibility matrix with mapping to organizational-specific jobs to ensure there are no gaps or overlaps in responsibility.
Business Capability System
This basic and fundamental need to exist, act, and behave as an enterprise creates a need to realize a business functionality, to form the ability, to have the motivations, people and things within activities needed, to perform and achieve the intended business of the enterprise.
Over time, the business functionality transforms into a business capability system, a systematic ability to satisfy the need for conducting business through:
- mission as a means to communicate and realize the idea and vision through goals, strategies, and other motivational influences,
- markets of sources of supply and demand,
- portfolio of holdings of offerings, operational and strategic capabilities,
- talent resident in a workforce with skills, abilities, knowledge and experience,
- operations of business to perform functional activities, and
- business management of the elements of the business capability, with the capability interconnected with all other capabilities.
In this way, the business capability system serves as the ‘infrastructural support’ system of the enterprise.
The business manager and business architect are responsible, respectively, for managing and architecting the business capability system.
As with the enterprise manager/architect role and all other functional roles, this is the point at which the ‘simplicity of basic and fundamental functional roles and responsibilities ends, and the point at which the transformation to organization-specifics begins.
As with all other functional roles, people are given positions assigning them to organizational jobs which assign the workforce to the (functional) roles. The positions and jobs have titles which may or may not be the same. In practice, there are many variations in role assignments and position and job titles. The following paragraphs will relate the more common organization-specific variations in the business management and architecture roles.
As with other functional roles, to satisfy specific organizational needs, the responsibilities of the business manager/architect role are specified through organization-specific job assignments.
Depending on the needs and abilities of the enterprise, the role can be filled by one job or many jobs, with responsibilities for the elements of the business capability allocated accordingly.
For example, from a functional role perspective, an organization-specific job focused on business management/architecture supported by managers/architects in a mission and portfolio job, a markets job, and an operations and talent job is shown in Table 5. Many other variations are possible including an organizational job for each functional role, or an organizational job for portions of a functional role, or portions of many functional roles. Variations in the business management/architecture roles are almost limitless.
For example in large organizations, to satisfy needs to level workload or needs for specialties in operations focused on functionalities of specific organizations, the operations role could, for example, be allocated to a business operations job in the organization focused on standard business capabilities which support all programs and a program operations job in the organization focused on program-specific capabilities, and the talent role specifically allocated to a talent job supporting the operations jobs in both organizations, as would the business management job, mission and portfolio job and markets job is shown in Table 6.
Table 5: Business Role by Functional Job Matrix
For example in large organizations, to satisfy needs to level workload or needs for specialties in operations focused on functionalities of specific organizations, the operations role could, for example, be allocated to a business operations job in the organization focused on standard business capabilities which support all programs and a program operations job in the organization focused on program-specific capabilities, and the talent role specifically allocated to a talent job supporting the operations jobs in both organizations, as would the business management job, mission and portfolio job and markets job is shown in Table 6.
When the business manager/architect role is supported by sub-roles in business management/architecture, the business manager/architect role enables and assures these supporting roles are integrated in their efforts and the overall business management/architecture effort, so that their management/architectures integrate with other management/architectures within and outside the business management/architecture.
Table 6: Business Role Allocation by Functional Job Matrix
In practice, the responsibilities of the business manager role are assigned through organizational job positions with various titles which may or may not be completely descriptive of the functions they serve.
Examples include “Business Manager”, “Program Manager”, “Marketing and Sales Manager”, “Manager of Professional Development”, “Business Development Manager”, “Business Operations Manager”, Financial Operations Manager”, “Finance and Accounting Manager”, “Subcontract Services Manager”, “Subcontract Operations Manager”, “Contract Manager”, “Procurement Officer”, Systems Engineering Manager”, “Security Manager”, “Plant Security Manager”, “System Security Manager”, “Configurations and Records Manager”, “Property Manager”, “Equipment Manager, “Service Manager”, “Service Program Manager” and “Project Manager, Development Programs”, just to name a sampling of titles.
In practice, the responsibilities of the business architect role are also filled through organization-specific positions, often with partially descriptive titles, as in the business manager role.
Examples include “Business Architect”, “Strategist”, “Business Portfolio Manager”, “Portfolio Manager”, “Talent Acquisition Consultant”, “Operations Architect”, “Business Consultant” and “Business Management Consultant”. Responsibilities are also allocated through leadership positions with titles such as “Chief Strategist” and “Chief Business Architect”.
It should be noted in practice, the business management/architect role is often fully or partially combined with other managerial/architectural roles to provide an organizationally needed ‘specialty’ job to address the special organization-specific needs and limitations of the organization. For example, “Business Information Architect” and “Business Technology Architect”.
In regard to practices, this organizationally overcomplicated allocation of responsibilities of the functional roles to the organizational jobs, where, for example, the organizational job “IT Portfolio Strategist” combines partial contents of multiple system elements, the business management/architecture community is the most difficult and confusing of the managerial and architectural roles to decipher EA practitioner responsibilities when it comes to understanding and communicating functional responsibilities through organization-specific jobs, titles, and nomenclatures. The issue is that the variations in the allocations of responsibilities have the risk of inadvertently missing the assignment of functional role responsibilities.
Therefore, as in enterprise management/architecture, business management and architecture plans, procedures, and practices should specify responsibilities through a functional-role responsibility matrix with mapping to organization-specific jobs to ensure all functionally required responsibilities are assigned.
Process Capability System
Increases in people and things within activities needed, drives the need to realize a process functionality, to form the ability, to understand, define, and communicate the conduct of business activities.
Over time, the process functionality transforms into a process capability system, a systematic ability to satisfy the need for understanding, defining, and communicating work activities through:
- policy to define business requirements for performing work activities, producing work products, and utilizing resources,
- procedure to define how to perform work activities, produce work products, and utilize resources per policy,
- roles to define skill-based functional work responsibilities for work activities, work products, and resources,
- workflow to define the flow of work activities, work products, and resources,
- process improvement to define the continuous improvement and sustainment of work activities, work products, and resources, and
- process management of the process capability, with the capability interconnected with all other capabilities.
In this way the process capability system serves as the ‘operational support’ system of the enterprise.
The process manager and process architect are responsible, respectively, for managing and architecting the process capability system.
As with the enterprise and business manager/architect roles, this is the point at which the ‘simplicity of basic and fundamental functional roles and responsibilities ends, and the point at which the transformation to organization-specifics begins. Organizational jobs assign the workforce to roles. Jobs have titles. In practice, there are many variations in role assignments and titles. The following paragraphs will relate the more common organization-specific variations in the process management and architecture roles.
To satisfy specific organizational needs the responsibilities of the process manager/architect role are specified through organizational-specific assignments.
For example, an organization-specific job focused on process management/architecture supported by managers/architects in a policy, procedure, and roles job, and a workflow and process improvement job is shown in Table 7.
When the process manager/architect role is supported by sub-roles in process management/architecture, the process manager/architect role enables and assures these supporting roles are integrated in their efforts and the overall process management/architecture effort, so that their management/architectures integrate with other management/architectures within and outside the process management/architecture.
In practice, the responsibilities of the process roles are filled through organizational positions with various titles which may or may not indicate an association with process management/architecture. Responsibilities are often merged into an organizational job with the managerial and architectural responsibilities of other capabilities. Confusing the situation further, the title “Process Manager” is sometimes applied to a job whose focus is management of an organization executing an organization-specific process, a practice common in the banking domain, for example a “Credit Card Process Manager” managing the “Credit Card Processing Department” with no responsibility to manage all processes-as-a-whole, but rather, having only the responsibility to manage the business system with the people executing their process only.
Table 7: Process Role by Functional Job Matrix
For this reason, other than the responsibilities being hidden within the jobs of many titles, ‘the rule’ is the function-based titles “Process Manager”, “Process Architect” and “Process Owner” are generally used when ‘communicating’ responsibility for a process-related role within a job with a non-process-related title. There are however exceptions to this rule for ‘dedicated specialty process jobs’, for example, a job focused specifically on process improvement is presented in Table 8, using organizational title labels in place of the functional job labels used in Table 7, as happens in large organizations.
Table 8: Process Role by Organizational Title Matrix
It should be noted in practice, the process management/architect role, as in other capabilities, is also often fully or partially combined with the enterprise manager/architect role or other managerial/architectural roles to provide an organizationally needed ‘specialty’ job to address the special organization-specific needs and limitations of the organization but is seldom reflected in organization-specific titles.
In regard to practices, because responsibilities for process capabilities are often allocated in varying allocations to jobs with multiple non-process roles and non-descriptive titles, the process management/architecture community is the most difficult of the managerial and architectural roles to determine coverage of EA practitioner responsibilities when it comes to understanding and communicating functional responsibilities through organization-specific jobs, titles and nomenclatures alone.
This difficulty is further compounded by a lack of attention to the details of process capability by practitioners whose focus is mostly the non-process capability part of the job and seldom the process capability part.
Sometimes the process capability is left unaccounted for, all of it thought to be addressed by the value-stream in business management and architecture and by automated processes and workflow in IT management and architecture, neither of which sufficiently covers any of the elements of the process capability system.
Therefore, it is imperative that process management and architecture plans, procedures, and practices should specify responsibilities through a functional-role responsibility matrix with mapping to organization-specific jobs to ensure all functionally required responsibilities are assigned.
Insight Capability System
As resources within activities increase, the need to capture, comprehend, recall, and apply what is both becoming known and what is already known increases, driving the need to realize an insight functionality, to form the ability to learn, understand, communicate, and apply what the enterprise explicitly knows.
Over time, the insight functionality transforms into an insight capability system, a systematic ability to learn, understand, communicate, and apply what is explicitly known through:
- data produced and used,
- information produced and used,
- configurations of the data and information produced and used,
- records of data, information and configurations,
- knowledge of data, information, configurations and records, and
- insight management of the insight capability, with the capability interconnected with all other capabilities
In this way the insight capability system serves as the ‘intelligential support’ system of the enterprise system.
The insight manager and insight architect are responsible, respectively, for managing and architecting the insight capability system.
Again, as with the other manager/architect roles, this is the point at which organization-specifics begin. Organizational jobs assign the workforce to roles. Jobs have titles. In practice, there are many variations in role assignments and titles. The following paragraphs will relate the more common organization-specific variations in the insight management and architecture roles.
To satisfy specific organizational needs the responsibilities of the insight manager/architect role are specified through organizational-specific assignments.
For example, an organization-specific job focused on knowledge and insight management/architecture supported by managers/architects in a data, information, and configuration job, and a record job is shown in
When the insight manager/architect role is supported by sub-roles in insight management/architecture, the insight manager/architect role enables and assures these supporting roles are integrated in their efforts and the overall insight management/architecture effort, so that their management/architectures integrate with other management/architectures within and outside the insight management/architecture.
In practice, the responsibilities of the insight manager role and insight architect role are filled through organizational positions with functional-type titles which generally indicate a direct association with insight management/architecture elements.
For example, “Insight (or Intelligence) Manager”, “Knowledge Manager”, “Information Architect”, “Data Architect”, “Configuration and Data Manager” and “Records Manager” are very common, to name a few.
When the insight manager/architect role is supported by sub-roles in insight management/architecture, the insight manager/architect role enables and assures these supporting roles are integrated in their efforts and the overall insight management/architecture effort, so that their management/architectures integrate with other management/architectures within and outside the insight management/architecture.
In practice, the responsibilities of the insight manager role and insight architect role are filled through organizational positions with functional-type titles which generally indicate a direct association with insight management/architecture elements.
For example, “Insight (or Intelligence) Manager”, “Knowledge Manager”, “Information Architect”, “Data Architect”, “Configuration and Data Manager” and “Records Manager” are very common, to name a few.
Table 9: Insight Role by Functional Job Matrix
It should be noted that in practice, the insight management/architect role is often fully or partially combined with the enterprise manager/architect role or other managerial/architectural roles to provide an organizationally needed ‘specialty’ job to address the special organization-specific needs and limitations of the organization. Examples include “System Data Architect” and “Process Knowledge Manager”.
Unlike business and process management/architecture, the insight managerial and architectural roles tend to be easier to associate to EA practitioner responsibilities when it comes to understanding and communicating functional responsibilities through organization-specific jobs, titles, and nomenclatures.
However, as with other capabilities, to ensure all functionally required responsibilities are assigned, insight management and architecture plans, procedures, and practices should specify responsibilities through a functional-role responsibility matrix with mapping to organization-specific jobs.
IT Capability System
Increases in needs for resources, activities, and insight drives the need to realize an IT functionality, to form the ability to provide IT products, systems, and services which support and enable the purpose for the resources, activities, and insight, and which also support and enable the mission and sustainment of the enterprise.
Over time, the IT functionality transforms into an IT capability system, a systematic ability to satisfy the need for IT products, systems, and services through:
- communications technologies including networks, smart devices, telecommunications, video conferencing, and other communication products and services,
- IT applications including software applications and programs,
- IT infrastructure including databases, data storage, and
- other infrastructural equipment,
- information utilization including the use of information and automated processes,
- procured IT services including communication technologies, applications, infrastructure, and information utilization services from external providers, and
- IT management of the IT capability, with the capability interconnected with all other capabilities.
- In this way the IT capability system serves as the ‘computational and informational support’ system of the enterprise.
The IT manager and IT architect are responsible, respectively, for managing and architecting the IT capability system.
Again, this is the point at which organization-specifics begin. Organizational jobs assign the workforce to roles. Jobs have titles. In practice, there are many variations in role assignments and titles. The following paragraphs will relate the more common organization-specific variations in the IT management and architecture roles.
To satisfy specific organizational needs, the responsibilities of the IT manager/architect role are, specified through organizational-specific assignments.
An example is an organization-specific job focused on IT management/architecture supported by managers/architects in jobs for each system element role, is shown in Table 10
Table 10: IT Role by Functional Job Matrix
In practice, as IT capabilities increase in size and complexity, the IT manager/architect sub-roles continue to be divided into increasingly specific specialty areas as the specifics drive specific needs for specific skill sets and knowledge specific to the associated capability. For example, the infrastructure role is often further divided into roles responsible for middleware, platforms, storage, networks, and security, each requiring a role skilled and knowledgeable in the specifics.
When the IT manager/architect role is supported by sub-roles in IT management/architecture, the IT manager/architect role enables and assures these supporting roles are integrated in their efforts and the overall IT management/architecture effort, so that their management/architectures integrate with other management/architectures within and outside the IT management/architecture.
In practice, the responsibilities of the IT manager role and IT architect role are filled through organizational positions with functional-type titles which generally indicate a direct association with IT management/architecture elements.
Examples include “IT Manager”, “IT Architect”, “Applications Architect”, and “Infrastructure Manager”. However, as with other capabilities, combinations and subdivisions in responsibilities will drive organizational titles that may not fully indicate which sub-elements of the capability are included.
As with other capabilities, in practice, the IT management/architect role is often fully or partially combined with the enterprise manager/architect role or other managerial/architectural roles to provide an organizationally needed ‘specialty’ job to address the special organization-specific needs and limitations of the organization.
Similar to insight management/architecture, the IT managerial and architectural roles tend to be easier to associate to EA practitioner responsibilities when it comes to understanding and communicating functional responsibilities through organization-specific jobs, titles and nomenclatures.
None the less, due to combinations of roles and all the subdivisions into increasingly specific roles, as with other capabilities, to ensure all functionally required responsibilities are assigned, IT management and architecture plans, procedures, and practices should specify responsibilities through a functional-role responsibility matrix with mapping to organization-specific jobs.
System Offering Capability System
Continued increases in functionalities, supports the needs of offering products and systems, forming the ability to realize a system offering functionality, an ability to develop and operate products and systems for customers.
Over time, the system offering functionality transforms into a system offering capability system, a systematic ability to satisfy the need for technology goods, products, or systems for a customer through:
- system needs for what the system offering must accomplish,
- system requirements for the system offering,
- system products needed for the system offering,
- system solution for the system needs,
- system abilities of the operating system, and
- system management of the system offering capability, with the capability interconnected with all other capabilities.
In this way the system offering system serves as the ‘technological support’ system of the enterprise.
The system manager and system architect are responsible, respectively, for managing and architecting the system offering capability system.
Organizational jobs assign the workforce to roles. Jobs have titles. In practice, there are many variations in role assignments and titles. The following paragraphs will relate the more common organization-specific variations in the system management and architecture roles.
To satisfy specific organizational needs the responsibilities of the system manager/architect role are, specified through organizational-specific assignments.
For example, an organization-specific job focused on system management/architecture supported by managers/architects in a system needs and requirements job, a system products job, a system solutions job, and a system abilities job is shown in Table 11.
Table 11: System Offering Role by Functional Job Matrix
In large organizations, for example, there is often a specialty job focused on overall system offering management/architecture with supporting system offering management/architecture jobs focused on specific capabilities or offerings, for example, widget system offerings, subsystem offerings, and integrated product offerings management/architecture.
When the system manager/architect role is supported by sub-roles in system offering management/architecture, the system manager/architect role enables and assures these supporting roles are integrated in their efforts and the overall system offering management/architecture effort, so that their management/architectures integrate with other management/architectures within and outside the system offering management/architecture.
In practice, the responsibilities of the system manager role are filled through organizational positions with various titles which are generally descriptive of the system-related roles and responsibilities. System-related responsibilities are also allocated through executive positions as with the other capabilities and offerings.
In practice, likewise, the responsibilities of the system architect role are also filled through organizational positions with various titles which are generally descriptive of the system-related roles and responsibilities.
For example, some practitioners are focused on system management/architecture applied to a specific systems domain, while others remain focused within system management/architecture working with a manager/architect role in a specific system domain. Responsibilities are also allocated through leadership positions.
It should be noted in practice, the system manager/architect role is often fully or partially combined with the enterprise manager/architect role or other managerial/architectural roles to provide an organizationally needed ‘specialty’ job to address the special organization-specific needs and limitations of the organization.
Relative to practices, because titles are generally descriptive of the systems domain, the system offering management/architecture community is generally not difficult to decipher EA practitioner responsibilities when it comes to understanding and communicating functional responsibilities through organization-specific jobs, titles, and nomenclatures alone.
Regardless, as in all capabilities and offerings, system offering management and architecture plans, procedures, and practices should specify responsibilities through a functional-role responsibility matrix with mapping to organization-specific jobs to ensure all functionally required responsibilities are assigned.
Service Offering Capability System
Continued increases in functionalities, including the development and operation of products and systems, supports the needs of offering services, forming the ability, to realize a service offering functionality, an ability to develop and operate services for customers.
Over time, the service offering functionality transforms into a service offering capability system, a systematic ability to satisfy the need for services for a customer through:
- service needs for what the service offering must accomplish,
- service requirements for the service offering,
- service catalog of the services needed for the service offering,
- service solution for the service needs,
- service abilities of the operating service, and
- service management of the service offering capability, with the capability interconnected with all other capabilities.
In this way the service offering system serves as the ‘serviental support’ system of the enterprise.
The service manager and service architect are responsible, respectively, for managing and architecting the service offering capability system.
Organizational jobs assign the workforce to roles. Jobs have titles. In practice, there are many variations in role assignments and titles. The following paragraphs will relate the more common organization-specific variations in the service management and architecture roles.
To satisfy specific organizational needs the responsibilities of the service manager/architect role are specified through organization-specific assignments.
For example, an organization-specific job focused on service management/architecture supported by managers/architects in a service needs and requirements job, a service catalog and solution job, and a service abilities job as shown in Table 12.
Table 12: Service Offering Role by Functional Job Matrix
In large organizations, for example, there is often a specialty role focused on overall service management/architecture with supporting service management/architecture roles focused on specific capabilities or offerings.
When the service manager/architect role is supported by sub-roles in service offering management/architecture, the service manager/architect role enables and assures these supporting roles are integrated in their efforts and the overall service offering management/architecture effort, so that their management/architectures integrate with other management/architectures within and outside the service offering management/architecture.
In practice, the responsibilities of the service manager role are filled through organizational positions with various titles. Responsibilities are also allocated through executive positions.
In practice, the responsibilities of the service architect role are also filled through organizational positions.
For example, some practitioners are focused on service management/architecture applied to a specific service domain, while others remain focused within service management/architecture, working with a manager/architect role in a specific service domain. Responsibilities are also allocated through leadership positions.
It should be noted in practice, the service manager/architect role is often fully or partially combined with the enterprise manager/architect role or other managerial/architectural roles to provide an organizationally needed ‘specialty’ job to address the special organization-specific needs and limitations of the organization.
Regarding practices, the service offering management/architecture community is generally not difficult to decipher EA practitioner responsibilities when it comes to understanding and communicating functional responsibilities through organization-specific jobs, titles, and nomenclatures alone.
Regardless, as in all capabilities and offerings, service offering management and architecture plans, procedures, and practices should specify responsibilities through a functional-role responsibility matrix with mapping to organization-specific jobs to ensure all functionally required responsibilities are assigned.
Summary and Conclusions
Looking at an enterprise as a system reveals a totally holistic and fully integrated view of an enterprise, its people, processes, information, and technologies.
As a system, the enterprise can be envisioned as it operates in the market environment to successfully deliver on its mission and satisfy its customers and stakeholders.
With the mission and goals of the enterprise driving the focus of interest within, the basic and fundamental needs of the enterprise drive the basic and fundamental capabilities to differentiate into broad and distinct high-level categories, based on what the capabilities are intended to do (their functionality) and the purpose they serve (their goal).
A business transformation team, as with all product, service, and need-driven teams, is composed of people with varying functionalities, all working towards serving a common need. Each specific executive, manager, and architect has a set of specific skills, abilities, knowledge, and experience related to a specific ‘discipline’ and understands the specifics of the specific functionality which satisfies the need. Each executive, managerial, and architectural discipline is assigned to roles with tasks, goals, and objectives requiring their skill set.
There are ‘working’ interdependencies (‘needs’ for work product inputs and outputs) between the ‘network’ of team members (skill-sets). It is these work product needs which form time-dependent relationships in the flow of this cross-functional work.
With roles and associated work products clearly differentiated, a working integration of cross-functional activities is promoted by defining the high-level flow of work and work products of each discipline and the time-phased back-and-forth work product dependencies between team members.
In summary, holistic enterprise architecture applied in its entirety to a business transformation, is not the job of a person. It is the job of a team, and each team member has a distinct function (a role) defining what they do.
Without the knowledge of how everyone fits in, and an understanding of expectations and cooperation between team members, the team will not succeed, regardless of the talent of the individuals.
The enterprise as a system perspective defines executive, managerial, and architectural roles in terms of the functionality they serve so team members can understand what they do regardless of what they are organizationally called, which varies from company-to-company, organization-to-organization, and job-to-job.
Each executive, manager, and architect has interdependencies with other executives, managers, and architects, and what the others do. With the knowledge of how everyone fits in, and the setting of expectations for the team, it can then organize, synchronize, and function to best utilize the talent of the individual team members, maximize workflow, and maintain control with minimal management in ‘out-of-flow’ conditions when agility, adaptability, and variance is needed.
Additional information is provided in my eBook “Defining Enterprise”, and by viewing my video “A Systems View of Whole-Enterprise Enterprise Architecture”.[15][16]
List of Acronyms
Acronym Explanation
a.k.a. also known as
BA Business Architecture / Business Architect
BIZBOK Business Book of Knowledge
CEO Chief Executive Officer
CFO Chief Financial Officer
CIO Chief Information Officer
COO Chief Operating Officer
CTO Chief Technology Officer
DODAF Department of Defense Architecture Framework
EA Enterprise Architecture / Enterprise Architect
EARB Enterprise Architecture Review Board
EBA Enterprise Business Architecture / Enterprise Business Architect
EITA Enterprise Information Technology Architecture / Enterprise Information Technology Architect
ERP Enterprise Resource Planning
FEAF Federal Enterprise Architecture Framework
INCOSE International Council on Systems Engineering
IT Information Technology
ITA Information Technology Architecture / Information Technology Architect
MODAF Ministry of Defense Architecture Framework
NIST National Institute of Standards and Technology
SoS System of Systems
SoSoS System of Systems of Systems
SoSoSoS System of Systems of Systems of Systems
SoSoSoSoS System of Systems of Systems of Systems of Systems
TOGAF The Open Group Architecture Framework
ZAF Zachman Architecture Framework
References
- Ross, Jeanne W., Peter Weill, and David Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, August 1, 2006. Available at https://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execution/dp/1591398398
- Bernard, Scott A. An Introduction to Enterprise Architecture: Third Edition, Paperback, August 13, 2012. Available at https://www.amazon.com/Introduction-Enterprise-Architecture-Third/dp/1477258000
- Lankhorst, Marc. Enterprise Architecture at Work: Modelling, Communication, and Analysis (The Enterprise Engineering Series), Aug 23, 2016. Available at https://www.amazon.com/Enterprise-Architecture-Work-Communication-Engineering/dp/3662517868
- FEAF, Federal Enterprise Architecture Framework Version 2, January 29,2013, Available at: https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf
- DODAF, Department of Defense Architecture Framework Version 2.02, Available at https://dodcio.defense.gov/library/dod-architecture-framework/
- MODAF, Ministry of Defense Architecture Framework Version 2.02, Available at https://www.gov.uk/guidance/mod-architecture-framework
- Zachman Architecture Framework, 2008, Available at https://www.zachman.com/
- BIZBOK, BIZBOK® Guide – Business Architecture Guild, Available through membership, Information available at https://www.businessarchitectureguild.org/
- TOGAF, The Open Group Architecture Framework (TOGAF®) Standard – Version 9.2, Available through membership, Information available at http://www.opengroup.org/subjectareas/enterprise/togaf
- NIST 500-167 Section 7. Information Management Direction: The Integration Challenge. NIST Special Publication 500-167, September 1989. Available at https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=900419
- ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description (last review 2017). Available at https://www.iso.org/standard/50508.html
- INCOSE. System of Systems Primer. 2018. Available to members of INCOSE at no cost at https://connect.incose.org/Pages/Product-Details.aspx?ProductCode=SoSPrimer
- Peter Checkland, Information available at: https://en.wikipedia.org/wiki/Peter_Checkland
- Brian Sauser and John Boardman, Systems Thinking: Coping with 21st Century Problems, 1st Edition, Available at: https://www.amazon.com/Systems-Thinking-Problems-Industrial-Innovation/dp/1420054910
- Defining Enterprise: A Systems View of Capability Management. Author-Publisher: Marc H Gewertz (February 5, 2017), ISBN 978-0-9981234-0-0 (PDF), ISBN 978-0-9981234-1-7 (EPUB), ISBN 978-0-9981234-2-4 (Mobipocket). Available at https://www.eabooks.net, https://www.amazon.com/Defining-Enterprise-Systems-Capability-Management-ebook/dp/B01MUV2VQ4, and other on-line retailers.
- A Systems View of Whole-Enterprise Enterprise Architecture Marc H Gewertz, Presented to INCOSE Chesapeake Chapter (May 17, 2017). Available at https://vimeo.com/218357721.
Table of Figures
Figure 1 – System (Open System)
Figure 2 – Technology System (Value-Adding System)
Figure 3 – Two Technology Systems
Figure 4 – Technology System of Systems
Figure 5 – Connecting the Process Dots
Figure 6 – Holistically Connecting the Dots
Figure 7 – Business System (Socio-Technical System)
Figure 8 -Two Business Systems
Figure 9 – Backup & Recovery Services System of Systems
Figure 10 – Desktop Applications Services System of Systems
Figure 13 – Business SoSoSoSoS
Figure 14 – Degrees of Communication & Understanding
Figure 16 – Enterprise System Concept Diagram
Figure 17 – Enterprise System Overview
Figure 18 – Enterprise Lifecycle
Table of Tables
Table 1 – Enterprise Role by Functional Job Matrix
Table 2 – Capability Oversight Role by Functional Job Matrix
Table 3 – Managerial Oversight Role by Organizational Title Matrix
Table 4 – Architectural Oversight Role by Organizational Title Matrix
Table 5 – Business Role by Functional Job Matrix
Table 6 – Business Role Allocation by Functional Job Matrix
Table 7 – Process Role by Functional Job Matrix
Table 8 – Process Role by Organizational Title Matrix
Table 9 – Insight Role by Functional Job Matrix
Table 10 – IT Role by Functional Job Matrix
Table 11 – System Offering Role by Functional Job Matrix
Table 12 – Service Offering Role by Functional Job Matrix
Note from the Editor-In-Chief Robert Halligan: I would like to publicly congratulate Mr. Gewertz on an outstanding article for PPI SyEN. Thank you Mr. Gewertz. The importance of enterprise/capability/business system architecture driven by enterprise/capability/business system needs as the starting point in problem definition/problem solving was well articulated in the 1994 systems engineering standard EIA/IS-632 and supported subsequently in EIA 632 and IEEE 1220 standards. Tragically, it was absent in the disastrous ISO systems engineering standard ISO/IEC 15288:2008 and its predecessor and, is still absent from the much better but problematic ISO/IEC/IEEE 15288:2015. In reading the article of Mr. Gewertz, I cannot help but contemplate the virtue of INCOSE, the Project Management Institute (PMI), the International Institute of Business Analysts (IIBA) and the Business Architecture Guild (BAG) federating with the objective of harmonizing the messages that each delivers to its constituency. There are, after all, humans with needs, and those who capture the needs and develop solutions.
3. Articles
3.1 Why Collaborations Fail
by
Jon Huggett
International advisor and coach to chief executives
Email: jon@huggett.com
Source: https://ssir.org/articles/entry/why_collaborations_fail
The board chair of a great social enterprise called me in distress. A collaboration he had nurtured was in disarray. He’d gotten ahold of an email that called the executive director and staff at his organization “uncollaborative”. He and I tried to figure out what was going on. We talked through the history of the collaboration and ultimately spotted what we thought could be the root of the problem: a major power shift. His organization had sprung from the partner years earlier. Both were financially healthy, but the “child” was now bigger and stronger than its “parent.” And the parent was feeling threatened.
Subsequently, he invested time with the chair from the other organization to hear his concerns. Then they each went back and opened up the conversation with their respective executive directors. Ultimately, the organizations resolved their differences and set a positive, “re-collaborative” course for the future.
For me, this experience exemplified the fact that power is the secret sauce of nonprofit collaborations. Great collaborations between organizations achieve more than either organization could achieve by itself. But when nonprofit collaborations don’t talk about power and address the implications of power imbalances openly, each party runs the risk of stumbling into (or contributing to) an ugly, counterproductive situation. This is true on an organizational level and a personal level, as relationships naturally grow and evolve over time. Sometimes, organizational and personal issues are one and the same. And sometimes the breakdown is irrevocable, and each party regretfully—and usually wrongly—walks away thinking the other was ultimately too uncollaborative.
The true nature of the problem
Over the past year, I have interviewed dozens of collaborators all over the world, at the request of a group of Australian nonprofits whose leaders wanted to better understand what effective collaboration looked like before working closely together. I observed many effective collaborations. I also observed an assortment of dysfunctional ones, where leaders and others privately confided that they felt the other party was uncollaborative. Based on these interviews and my own experience, I’ve identified three major types of power struggles, where one party (either an organization or individual) implies the other is “bad”, “sad”, or “mad.”
- Bad: The last time someone called me uncollaborative was when I engaged—and enraged—a fellow board member. This person had been perennially late to and ill-prepared for many regular meetings. In this instance, she had not been a full participant in discussions leading up to a hard-won board decision regarding donations from the board members themselves. The rest of the board had put in the legwork to work out differences and come to a consensus on our “give or get” policy, only to have her throw up last-minute objections to our preference for giving. I was angry, and I admit that my words that day were impolite. I asked her why, since she was clearly the richest person on the board, she had donated the least out of all of us.She did not respond in kind but later emailed the rest of the board members saying I was uncollaborative. What she meant was that I was being “bad” by trying to hold her accountable. The real issue, of course, was power. I was out of line in my remarks, but my sin had not been lack of collaboration, it had been to challenge her power and call out her abuse of it. I insinuated that she was “bad” too. We both could have done better.
- Sad: This is when one party suggests the other isn’t being collaborative because they are somehow less clever—less capable of the sophistication of thought needed to understand or address a particular situation. I served many years on the board of a global project, where an executive director urged us to be more collaborative. We weren’t “thinking holistically” or “considering the nuances,” but he didn’t bother to explain. This is another unhelpful assertion of power—the power of knowledge. An organization or individual who urges their partner to consider “systems thinking” without naming the systems or sharing the thinking does nothing to level the playing field. The word is uncollaborative, but the message is “I don’t think you can understand this, so just give me the power.”
- Mad: “You’re being uncollaborative! You need to put your ego to one side,” says one party. Or, “You take things too personally; that’s why you’re difficult to collaborate with.” These kinds of comments aren’t about collaborating; they’re about claiming the power to judge the judgement of another party. I’ve been out as a gay man in the workplace for decades and have lost count of the times when female colleagues or I have been asked to step aside because we are “too sensitive.”
Getting power dynamics right
It doesn’t have to be this way. In fact, many of the successful collaborations I’ve observed seem to get power right from day one. Specifically, ones that:
1. Set clear goals.
Clear, concrete goals empower collaborators to make decisions on their own, whereas when goals are fuzzy, participants need to ask approval from those with power. Take the President’s Emergency Program for AIDS Relief (PEPFAR), whose goal is to save lives. The organization collaborates with governments, NGOs, and companies across a huge range of cultures, values, and policies. But that single goal keeps things moving. In a conversation I had with Ambassador-at-Large and US Global AIDS Coordinator Deborah L. Birx, she put it this way: “We have made our public-private partnership very intentional and clear: Private sector partners join with us as they share our goal, and there is a clear win for us and for the private sector, and together we bring the best of all members for maximal impact. Across all aspects of the partnerships, there must not only be the shared goal, but clarity and transparency along the pathway of achieving the goal.”
2. Recognize each other’s legitimate needs, which may differ.
Even if collaborators share a common goal for impact, individually they may need funding to support their own agendas or particular needs. It is better to acknowledge and respect these differences than to ignore them. By doing so, each organization can make a distinct case to funders, and together, they can better articulate why the collaborative effort is attractive.
Sometimes, a merger is the answer. One CEO I talked to described a merger between her organization and another this way:
The logic of the merger was to gain power: We could speak with one voice to the government. We had tried to collaborate before, but we were competing for funding. The two CEOs agreed that the merger made so much sense. Neither of us wanted to be “co-CEOs.” We asked that they decide early on which of us would get the job and give the other one assurance of pay until the merger, and then six months’ pay afterwards to find another job. We were able to make the merger a success and continue our careers afterwards.
Beware the funder that wants grantees to collaborate around a shared vision, such as better mental health. This may seem like an ideal “clear goal” at the start, but in such cases, the funder holds all the power. Funding collaborative efforts gives philanthropists a birds-eye view of innovations and keeps their options open for the future (allowing them to determine which goals to pursue, which entrepreneurs to back, and when to start building institutions that may be central to systems change). But grantees may find themselves pitted against one another or compelled to double down on fundraising efforts to meet their other needs. Unless the funder can bring in new sources of power—such as government—grantees may not have much to gain and may have a lot to lose.
3. Set clear roles, showing which parties have more power over others, and why.
Clear roles help partners build trust, even if the new roles shift power. In other words, it’s easier for me to act if I know what power I have and what power you have, even if you have much more power. It’s harder when the power is ambiguous. As Dan Berelowitz, founder of Spring Impact and the International Centre for Social Franchising, says: “Social franchising is an idea that works with a great power imbalance, because its roles are clear. Everyone knows where they stand.” Social franchising applies commercial franchising means to social ends. It works because both franchisor and franchisee know their roles, which decisions they can make, and what they cannot do. The clarity is especially important if the franchisor has much more power than the franchisee.
And as Andrew Barnett, director of the UK branch of the Calouste Gulbenkian Foundation points out: “[Philanthropists] have all the money and time that we need … We can bring in all kinds of power to propel a collaboration: government, other sectors, citizens. We all have to surrender some power [as well]. It’s critical for funders to be open to alternative perspectives and even to challenge what we may find initially uncomfortable.”
Leveraging strengths, compensating for weaknesses
Setting goals, understanding and meeting needs, and clarifying roles are steps collaborative partners need to take to leverage their strengths and compensate for each other’s weaknesses. If your collaboration hits a rough patch and it appears that an uncollaborative partner is causing it, remember: Following the power trail may illuminate the real issue—and point to a solution.
About the author
Jon Huggett (@jonhuggett) was the first chair of the Social Innovation Exchange, which has members across Asia, the Americas, Europe, and Australia. He has also chaired the boards of Organization for Refuge, Asylum and Migration, STOP AIDS Project in San Francisco, Khulisa in the United Kingdom, and the global campaign All Out. He also serves on the board of Zitter Health Insights, and advises businesses and social enterprises around the world.
Article
3.2 Integrating Program Management and Systems Engineering
by
Ralph R. Young
Editor, SyEN
Email: ryoung@ppi-int.com
This month we provide a summary of Chapter 13, Integration Means Change, in Integrating Program Management and Systems Engineering (IPMSE), a collaboration of the International Council on Systems Engineering (INCOSE), the Project Management Institute (PMI), and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts (USA) Institute of Technology (MIT). This is our fourteenth article in this series. Our objective in providing this series is to encourage subscribers to leverage the research base of this book that has provided new knowledge and valuable insights that will serve to strengthen the performance of complex programs. “The Book” is highly recommended as professional development for all systems engineers and is available to members of INCOSE at a discount, purchasable here.
Chapter 13 is the first of three chapters in Part III of The Book, labelled Developing Integration Competencies in Your Organization (Chapter 14 is titled Successful Change Programs that Improved Integration; Chapter 15 is titled Leading an Integration Change Program).
Recall from the Summary of Chapter 12 that was provided in last month’s issue of PPI SyEN that the research results illustrated how effective integration between program management and systems engineering disciplines produces value for the organization:
- Through traditional measures of program performance such as requirements fulfillment and client satisfaction.
- Additional tangible benefits that include a more reliable program performance with fewer deadline overruns.
- Added competitive agility.
- Strengthened teamwork.
- More effective communication.
Chapter 13 begins with an overview of what is required to produce sustained change in complex organizations. An organization, and particularly an organization that employs systems engineers, program managers, project managers, and sophisticated technical experts, is a complex, interdependent network of resources, processes, and technologies that create value for the organization and its beneficiaries (clients, customers, receivers) through the work they produce. A continuous improvement change program must take into account the multiple dimensions of the organization, including stakeholder needs and values, the organizational structure and culture, and the interconnectivity of functions within. Organizational transformation modifies an organization while it is in action and moves it from its current state to an envisioned future – a process that requires a significant change in approach, mindset, the adoption of a holistic view of how the program will work, and a comprehensive plan for execution of the change program. Integration will require change and change is difficult. Most organizations will require concerted and deliberate effort to effectively implement and manage the change to realize benefits. Further, sustaining change over time requires ongoing effort to reinforce and support the new way of working together.
A Model for Sustainable Change developed by the Project Management Institute (PMI)[19] is provided that includes the following components:
- Support from the top
- Utilize change-sustaining approaches
- Shift paradigms when needed
- Talk and communicate
- Assimilate and integrate
- Invest in planning for sustained results
- Negotiate results with a portfolio approach
SUSTAIN
This model suggests an intentional approach for organizations (see page 262 of The Book for more details). The intent is to ensure that all of the highly interrelated elements of the change program receive ongoing attention. It is emphasized that many organizations undertake extensive change initiatives but many fail to achieve their objectives or are unable to sustain the change. Research has found that a holistic systems approach is required to achieve lasting, effective change.[20] A change program must take into account the multiple dimensions of the enterprise, including its various stakeholder needs and values, the culture of the organization, and the interconnectivities of different functions of the enterprise such as design, manufacturing, the supply base, and on and on.
Implementing change in a complex program environment requires systems thinking, a fundamental concept for systems engineers. Systems thinking involves understanding that a system exists within a wider context and/or environment, and that a system is made up of parts that interact with each other and the wider context. Systems thinkers consider an issue fully, resist the urge to come to a quick conclusion, and consider both short- and long-term consequences (INCOSE, 2015).
Many who seek to implement change in an organization rush into implementation before first providing the groundwork for success. The upfront effort to consider how the organization will respond to the change and how best to nurture the change has significant payoffs. Further, consistent follow-through will be needed to sustain the change long term. Successful and sustained change in complex program environments requires a system of change that works hand-in-glove with the organization’s objectives, business systems, leadership, culture, and daily operations.
The reason for failure of change programs often can be traced to some form of resistance to change. Resistance to change is typically thought of in terms of individuals not supporting the change – either passively or actively. While individuals are one source, resistance can be defined as anything – people or systems – that pushes against the change. In one way of thinking, forces pushing for the change and forces pushing against the change are identified and analyzed. When the forces pushing for the change exceed the forces pushing against the change, then, and only then, will change happen in a sustainable way. Therefore, it is important to be aware of common forces of resistance so that their force is minimized or eliminated.
Nightingale and Srinivasan[21] identified eight common failures of transformational change that are described in Table 13-1 on page 264 of The Book. One key element common to all of the failure types is the absence of taking a systems approach to change, which results in some form of resistance. You might take a closer look at the examples from the list to understand how these types of failures might emerge as a source of failure in integration efforts. Review and consideration of these potential stumbling blocks may be both invaluable and useful.
The change process begins with the establishment of the driving business reason for change. The Strategic Phase begins with identifying the strategic imperative for change, and, at a high level, stating the strategic objective of the change. This is about the business case and answering the following questions:
- Why do we need to do this?
- What is the business value we are trying to achieve?
- What if we do not integrate?
A Planning Phase provides a transformation program plan. The plan must have elements related to each of the inputs in the Integration Framework (this framework was described in this series in PPI SyEN 61 – January 2018[22]): processes, practices, and tools; organizational environment people competencies; and contextual factors. In addition, a benefits roadmap would be one of the outputs of planning.
Stakeholder identification and analysis is critical and is described on pages 269-270 of The Book. Also provided is a description of the characteristics of a change agent.[23]
Assessing an enterprise’s readiness for change is an important part of the strategy phase in a transformational change effort. It is important to understand that what is being assessed is cultural readiness, commitment readiness of key stakeholders and resources, and the capability of the organization to be able to expend resources to implement and sustain the change.[24]
Industry tools for developing a readiness assessment are noted, including the Baldridge Performance Excellence Program, the Capability Maturity Model Integration (CMMI), and the LAI Self-Assessment Tool (LESAT).
Combe recommends keeping in mind that “Change readiness takes a critical look at an organization’s resolve, fit, and capacity to successfully deliver the benefits of a proposed program or project, and initiates appropriate actions to bring a current state of readiness to one of confidence in long-term success of the program/project outcomes”.
With senior leadership committed to and personally engaged in achieving the benefits the change will bring about, others within the organization will be inspired to do what it takes to see the change through so that it succeeds and continues to produce value for the organization well into the future.
Research indicates that companies that adopt formal approaches to integrating program management and systems engineering roles are likely to achieve more complete integration of those disciplines.[25] The importance of careful planning and the sustained engagement of senior leaders cannot be overstated. IBM reported findings from its survey of CEOs regarding strategy implementation.[26] The top challenges to success included:
- Changing mindsets and values (58%)
- Corporate culture (49%)
- Underestimation of complexity (33%)
You may want to identify effective change agents in your program management organization and in your systems engineering organization and thoughtfully consider examples of transformation initiatives or changes that your organization has already experienced – were these successful? Why or why not? Why is taking a systems approach to transformation more likely to succeed?
References
Changefirst. “A Research-based Exploration of the Role of the Change Agent in Organizational Change”. White Paper retrieved from http://www.changefirst.com/, 2011. Changefirst is a company based in the UK, Australia, and Brazil that delivers services globally. Changefirst started providing a set of ten change-related tools online for its clients in 2006. The company now has a significant database with over 26,000 respondents and almost 400,000 data points. The data is held it its Enterprise Change Management Platform called e-change and is available to be utilized by practitioners on a subscription basis.
Changefirst. “The Power of Data: Understanding Change: Legacy and Tracking Risks”. White Paper retrieved from http://www.changefirst.com/, 2014. The challenges of implementation of change projects are often underestimated. Changefirst has an “Initiative Legacy Assessment” that provides an early diagnosis of an organization’s readiness to undertake a change project. Another change-related tool, the Initiative Risk Assessment, allows for measures to be taken across the change lifecycle, enabling measurement of the commitment to change at announcement of the change, the early stages of implementation, mid-way through implementation, and when the change project is nearing the end of implementation. Changefirst’s People-Centered Implementation methodology (PCI) is designed to increase commitment to the change project while it is underway. The paper concludes with a call to action for leaders and practitioners to take actions to improve commitment to the change project.
International Council on Systems Engineering (INCOSE). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (4th Ed.). D. Walden, G. Roedler, K. Forsberg, R. Hamelin, T. Shortell (Editors). Hoboken, New Jersey USA: John Wiley & Sons, 2015.
Marrewijk, Alfons van. “Digging for Change: Change and Resistance in Interorganizational Projects in the Utilities Sector”. Project Management Journal, 49(3), 34–45, 2018. White Paper available at https://www.pmi.org/learning/library/digging-for-change-11263 . Delivering organizational change through interorganizational projects is a complex process, since several organizations must collaborate. The aim of this article is to understand how change and resistance are shaped in interorganizational projects. This article discusses a longitudinal case study (2012–2016) of an interorganizational project in the utility sector. The findings of the study describe four practices that both enabled and constrained change. The contribution of the article is an extension of our understanding of change and resistance in projects with the introduction of the notion of productive resistance and the notion that employees can be change agents and middle managers can be resisters.
Miller, D. “Successful Change Leaders: What Makes Them? What Do They Do That is Different?” Journal of Change Management, 2(4), 359-368, 2002.
Miller, David, and Mike Oliver. “Engaging Stakeholders for Project Success”. PMI White Paper available at https://www.pmi.org/learning/library?q=Engaging+Stakeholders+for+Project+Success. This paper is described in the SE Publications section of this issue of PPI SyEN.
Monat, Jamie P. and Thomas F. Gannon. Using Systems Thinking to Solve Real-World Problems. United Kingdom: College Publications, 2017. This book was described in the SE Publications section of the July 2018 issue of PPI SyEN.
Project Management Institute. Managing Change in Organizations: A Practice Guide. Newtown Square, Pennsylvania USA: Author.
Rockwood, K. “Built to Transform: Big Business and Big Changes Go Hand in Hand; a Few Key Forces are Driving Today’s Change Management Mania”. PM Network, 32(6), 30–33, 2018. PMI White Paper available at https://www.pmi.org/learning/library/built-transform-change-management-11282
Roth, George L. and Anthony J. DiBella. Systemic Change Management: The Five Capabilities for Improving Enterprises. London, England: Palgrave Macmillan, 2015.
4. Systems Engineering News
4.1 INCOSE Launches New Systems of Systems Primer
Source: INCOSE Website
The INCOSE Systems of Systems Primer was launched at the INCOSE International Symposium in July 2018 and is available for free download from the INCOSE Store here.
What is a System of Systems?
A System of Systems (SoS) is a collection of independent systems, integrated into a larger system that delivers unique capabilities. The independent constituent systems collaborate to produce global behavior that they cannot produce alone. Systems of Systems is becoming a topic of increasing interest. The SoS working group has been implementing a set of activities including monthly global webinars and a special issue of INSIGHT, the INCOSE Practitioners’ Magazine, focused on SoS to support information exchange on systems engineering for SoS.
What is the Systems of Systems Primer?
The SoS Primer is intended to reach a broader audience. The primer will serve as an effective introduction to the SoS area, while also providing a roadmap for the reader on where to find additional information.
Why should I care about Systems of Systems?
Many systems engineers (SEs) work in an SoS context at some time during their careers – perhaps without even realizing it. This could be as an SE in a constituent system, or directly working on the SoS functionality itself. SoS contexts are associated with specific challenges, and the existence of the SoS places long-term, evolving requirements on each of the constituents. Without an awareness of the wider SoS context, engineers on separate constituent systems run the risk that their system will struggle to meet operational requirements in the long term, even if it currently meet its immediate requirements.
INCOSE Systems of Systems Primer Introductory Video on YouTube
Note by the Editor-In-Chief Robert Halligan: Two resistors, a capacitor and a chip all on a circuit board would meet the definition above. Widely used typical criteria for a “System of Systems”, embraced by the INCOSE System of Systems Working Group, I believe, are (Maier 1998,):
- Operational Independence of Elements
- Managerial Independence of Elements
- Evolutionary Development
- Emergent Behavior
- Geographical Distribution of Elements.
De Laurentis 2005 has added three arguable additional criteria. The two last Maier criteria are quite strange. Emergent behavior, whilst valid, is a characteristic of every system. If there is no emergent behaviour, it is not a system. Geographical Distribution of Elements is also strange. A city public transport system comprising metro rail, two commercial bus services, UBER, a taxi system, and private road transport is a system of systems which are typically operationally and managerially independent. But they have geographic overlay, not geographic distribution.
4.2 New Purdue Center to Develop Scientific and Engineering
Principles of Resilient Systems
Article available here.
What causes some systems — computing, cyber physical, or large-scale engineered systems — to be resilient to disruptions of various kinds? And what causes some systems to bounce back from a failure quickly?
A new Purdue University College of Engineering (West Lafayette, Indiana, USA) center has been unveiled to seek the foundational design principles that underlie resilient systems. The Center for Resilient Infrastructures, Systems and Processes (CRISP) was officially started in October 2017 and will run its seed grant competition for research proposals this summer.
The center involves faculty members in leadership roles from multiple engineering departments, including director Saurabh Bagchi, a professor of electrical and computer engineering; associate directors Jitesh Panchal, a professor of mechanical engineering, and Milind Kulkarni, a professor of electrical and computer engineering. Three thrust leads positions, including Gesualdo Scutari, a professor of industrial engineering, on optimization; Felix Lin, a professor of electrical and computer engineering on cyber-physical systems; and Srinivas Peeta, a professor of civil engineering on large-scale civil infrastructures.
Society is crucially dependent on several interdependent critical infrastructure systems and processes for operating these systems. These are subjected to various kinds of hazards and faults, both natural and malicious, often leading to user-visible failures. The CRISP center will provide scientific methods to analyze the failure modes of the infrastructures and provide engineering tools to systematically build in resilience. Initial focus areas will be resilient and adaptive cyberinfrastructures, resilient cyber-physical systems, and scientific foundations of resilient socio-technical systems. The researchers will develop techniques that apply broadly across multiple domains to complement existing domain-specific techniques.
“We know several design principles that enhance resilience, such as, composability and decoupling,” Bagchi said. “We need to develop the scientific discipline of resilience as it applies to cyber, cyber physical, and socio-technical systems. Our center by bringing together the leadership team and approximately 20 affiliate faculty members is uniquely positioned to address the end-to-end resilience challenges. Such challenges are becoming more pressing as our society depends more heavily on these large-scale engineered systems.”
Kulkarni, who will lead that thematic area of resilient cyber systems, stressed on the need to build adaptable software systems, such that they can adapt to new hardware platforms, including mobile platforms and large volumes of data.
“To complement the scientific principles, we have to develop practical techniques to make an existing system resilient to certain vulnerabilities, without significantly compromising the performance and the functionality of the system,” Kulkarni said.
The result of CRISP’s activities would be a building code for designing resilient systems, a task-oriented checklist for engineering resilient systems, and a wind tunnel for verifying that the system meets its resiliency and functional goals.
“How do we enable engineering enterprises to use a significant but underutilized mode of innovation by communities of employees within organizations, and of enthusiasts outside the organizations,” Panchal said. “Through our efforts, we are establishing foundational techniques for modeling and analyzing the evolutionary dynamics of complex networked systems, such as digital distributed manufacturing and road transportation.”
Two notable upcoming activities of the center are a seed grant competition and a workshop on resilience. The seed grant competition will accept research proposals from multi-disciplinary teams due on July 20. Each grant will fund one graduate research assistant for the 2018-19 academic year.
The second activity is a workshop to be held this fall on the Purdue campus with a set of distinguished as well as promising young researchers from academia and industry. There will be several opportunities through panels and poster sessions for the Purdue community to participate in the workshop.
The center is currently funded by Purdue and existing contracts in the labs of the leadership team members broadly focused on the topic of resilience.
Further details can be found from the CRISP website at www.purdue.edu/crisp.
4.3 Computer Science Research Is Lacking In These Key Areas
by Mohamed Sarwat, Computer Science faculty at Arizona State University
Over the past few decades, computer science research, either in industry or academia, has led to groundbreaking technology innovations such as the Internet, which continues to change our lives.
Generally, computer science research has been driven by one of the following factors:
(1) New hardware: Moore’s law always impacts the way we design algorithms and implement software systems. In the post-Moore’s Law era, advances in cloud computing affected so many sub-areas of computer science like operating systems and database systems. Furthermore, solid state drives (SSDs) changed the way we design storage systems, which were previously tailored for the mechanical hard drive (HDD). Recently, quantum computing promises lightning-speed calculations as opposed to classic electronics-based computers. In the future, advances in quantum computing research may drastically change the way we design and implement computer systems.
(2) New applications: Emerging applications such as autonomous cars and cryptocurrency have called for novel computing systems that can enable such applications. Autonomous cars triggered AI and data science researchers to develop novel algorithms to enable effective, robust, and safe self-driving cars. Moreover, the emergence of Bitcoins led to the development of the Blockchain technology, which enables the robust exchange of cryptocurrencies and digital assets without the need of a central authority.
Beyond these though, I believe the following areas also need further attention:
1. Data system support for the Internet of Things: Internet of Things simply means that smart devices equipped with sensors and actuators keep generating data from the local environment. Such devices (i.e., things) then send such data to the cloud via the internet for further processing. The flow of data from devices to the cloud and back is currently done in a random manner, wasting time, resource, and energy. Finding effective data management strategies between the edge and the cloud could have a huge impact on real-time applications.
2. Personal data protection systems: Recent data breaches, e.g., Equifax, and data abuse such as the Facebook-Cambridge Analytica incident have triggered a red alert. Such incidents call for designing and developing robust personal data management systems that protect not only privacy, but also data ownership and transparency. GDPR recently took effect in Europe. The question of how existing data systems adapt to such regulations may impact how companies run businesses today. For instance, companies like Oracle may provide a version of their Oracle Database Management System (DBMS) that is GDPR-compliant. That may lead to tremendous changes in the DBMS stack from data storage systems to query processing algorithms.
Other important, yet underdeveloped, research areas include but are not limited to leveraging AI to improve the healthcare system, transportation, and global security challenges. The Master of Computer Science offered by ASU both on campus and online via Coursera offer subjects related to cutting edge technology in the areas of big data, artificial intelligence, and cybersecurity. The offered courses give students hands-on experience with state-of-the-art technology and hence prepare them to pursue a research-oriented degree/career in the future.
4.4 SysML V2 Status
The Object Management Group® (OMG®), an international, open membership, not-for-profit technology standards consortium, issued a Request for Proposal (RFP) for SysML® v2, which will aims to the precision, expressiveness, and usability relative to SysML v1. In order to influence the future of SysML, both members of OMG and non-members must submit a Letter of Intent to show their interest in participating in the process by September 24, 2018. In order to become a submitter, individually or as part of a submission team, companies must become members of OMG by the initial submission deadline of November 4, 2019.
The issuance of this RFP culminates a 1.5-year effort by the SysML v2 RFP Working Group to develop the requirements for the next-generation systems modeling language.The requirements reflect lessons learned from applying MBSE with SysML since its release more than 10 years ago. The RFP requires the specification to include both a SysML profile of UML®, a SysML metamodel, and a mapping between them. In addition, submitters have the option to specify additional features that include model interchange and formal semantics.
Sandy Friedenthal, the SysML v2 RFP Working Group Chair, said “There is strong enthusiasm among the systems engineering community to move forward with SysML v2, and provide capabilities that enable improved effectiveness and broader adoption of MBSE.”
A complementary RFP entitled the “SysML v2 API and Services RFP” has been developed to enable interoperability between SysML modeling tools and other model-based engineering tools. This RFP was issued in June 2018.
The objectives for SysML V2 are at http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group
5. Featured Organizations
5.1 Massachusetts (USA) Institute of Technology (MIT)
Sociotechnical Systems Research Center
(SSRC)
The MIT Sociotechnical Systems Research Center (SSRC) is an interdisciplinary research center that focuses on the study of high-impact, complex, sociotechnical systems that shape our world. SSRC is affiliated with the new MIT Institute for Data, Systems, and Society (IDSS).
SSRC brings together faculty, researchers, students, and staff from across MIT to study and seek solutions to complex societal challenges that span healthcare, energy, infrastructure networks, the environment, and international development.
Mission
SSRC develops collaborative, holistic, systems-based approaches to complex sociotechnical challenges.
Vision
SSRC is a vibrant, global, interdisciplinary community with a shared interest in analyzing and proposing solutions to complex sociotechnical systems issues.
Current SSRC Research:
Making Lean Thinking Part of the DNA of Engineering Program Management
The SSRC staff includes, among others:
Ali Jadbabaie
Director
Email: jadbabai@mit.edu
Stephanie Toews Moeling
Administrative Officer
Email: srichar@mit.edu
5.2 MIT Consortium for Engineering Program Excellence
(CEPE)
Within the MIT Sociotechnical Systems Research Center (SSRC), the MIT Consortium for Engineering Program Excellence (CEPE) supports lean thinking within large-scale engineering programs by integrating program management, systems engineering, product development, and systems engineering approaches.
Mission
- Help organizations achieve competitive advantage by systematically improving the performance of their engineering programs
- Provide thought leadership
- Develop practical tools that facilitate the performance improvement of engineering programs
CEPE focuses on:
- Integrating the key knowledge areas of program management, systems engineering and product development, lean thinking, and organizational change
- Focusing management activities to create a respectful environment for knowledge work, increase effectiveness by clearly defining stakeholder value, and maximizing efficiency through the elimination of waste
- Defining the root causes of engineering program challenges; clarifying improvement needs; and identifying, developing, and describing drivers of top engineering program performance
- Helping members to identify and create best practices, and help members develop practices in their engineering programs that consistently achieve world-class cost, schedule, and technical performance
- Creating a vibrant community of leading organizations and experts in the fields of program management, systems engineering, and lean thinking to facilitate experience exchange and community learning
- Supporting key decision makers in government and industry to eliminate barriers to widespread use of best practices
CEPE leadership includes:
Weber-Shaughness Professor of Mechanical Engineering and Engineering Systems
Co-Director, System Design and Management Program
Email: seering@mit.edu
Research Associate
MIT Consortium for Engineering Program Excellence
Email: erebenti@mit.edu
Note that Eric is the Editor-in-Chief of “The Book”: Integrating Program Management and Systems Engineering, a collaboration of the International Council on Systems Engineering (INCOSE), the Project Management Institute (PMI), and the Consortium for Engineering Program Excellence (CEPE) at the Massachusetts (USA) Institute of Technology (MIT). The Program Performance International Systems Engineering Newsletter (PPI SyEN), has sponsored a series of articles describing each of the chapters of The Book since March 2017. The article provided earlier in this issue is the fourteenth article in this series. See https://www.ppi-int.com/syen-newsletter/ to review previous issues of the PPI SyEN issues that include these articles.
6. News on Software Tools Supporting Systems Engineering
6.1 Schedule Compliance Risk Assessment Methodology (SCRAM)
by
Angela Tuffley
Director, RedBay Consulting.
Email: a.tuffley@redbay.com.au.
According to Gartner[27] the single most common reason that projects were considered a failure, irrespective of project size, was because they were substantially late. In fact two-thirds of the Gartner survey respondents considered the challenges of bringing projects in on time, on budget, and with the agreed functionality as the primary causes of project failure. Schedule slippage is a symptom of any number of problems or causes occurring on a project. Identifying root causes of schedule slippage is not always easy but is necessary if schedule slippage is to be remedied and managed.
The Schedule Compliance Risk Assessment Methodology (SCRAM) is a structured, repeatable engineering-focused review used to identify the root causes of issues and risks to schedule and to recommend remedial actions. Developed in partnership between the Australian Department of Defense Capability Acquisition and Sustainment Group (formerly the Defense Materiel Organization) and industry, SCRAM has been applied successfully on more than 32 Australian and international complex defense projects in Australia, USA, and the UK across multiple technology domains including aerospace, maritime, communications, aircrew training, satellite ground control, and command and control.
SCRAM can be applied at any point in the system life cycle from pre-contract award through to production and sustainment. It embodies best practices from systems engineering, software engineering, schedule development, and project management. It quantifies the schedule impact of issues and risks using the scientific analysis techniques of Schedule Monte Carlo Simulation and Software Parametric Modelling.
The SCRAM Review process is NOT an audit. It is minimally disruptive, independent, non-attributional, transparent, and non-advocate in which both customer and contractor are reviewed and provided with the results based on corroborated objective evidence and data, thereby providing joint benefits within two to four weeks.
The SCRAM Review Process
During a project’s life cycle, project managers are flooded with a wealth of information on the progress and status of their projects and the challenge is to bring order to chaos so that effective action can be taken to address problems. SCRAM Reviews use a defined review process shown in Figure 1 delivered by Certified SCRAM Assessors utilizing a structured framework containing interdependent categories called the Root Cause Analysis of Schedule Slippage (RCASS) model (shown in Figure 2).
Figure 1: SCRAM Review Process
Figure 2: SCRAM RCASS Model
The results of a SCRAM Review are presented based on the RCASS model; allowing senior leadership and management to quickly understand the impact / implications of identified root causes regardless of the technical complexity involved. Where sufficient project data exists, review results include a forecast of the probability of achieving critical milestone dates (e.g. delivery) based on the SCRAM Team’s identified issues, risks and technical data which typically are not recorded in the project’s risk log. The results are supported by SCRAM Team recommendations to help the project get back on track; however, these recommendations are non-binding.
SCRAM Successes
Over the years, the SCRAM milestone forecasts have proven to be quite accurate including forecasts for the F-35 on-board software (approximately nine million lines of source code) and the off-board support software encompassing logistics, training, and mission planning. A testimony to the accuracy of those forecasts was provided by Lt. Gen. Christopher Bogdan, the former Program Executive Officer for the F-35 Program:
“SCRAM gave us new techniques for measuring the progress of software development and for predicting how long the software development was going to take. In 2014, I briefed the SCRAM results to the Defense Acquisition Board. Of all the organizations that were making estimates, the SCRAM estimates, in hindsight, were the most accurate.”
– Lt. Gen. Christopher Bogdan, Program Executive Officer, F-35 Program (2012-17)
Much of SCRAM’s success is also due to the non-advocate, collaborative, and transparent approach that serves to build trust from programs and projects being reviewed, who often ask the question “How can this hurt us?” Instead, a SCRAM Reviews focus on how to help the program so they can achieve success. The following comments from the government Joint Program Office for the largest defense program ever undertaken, the F-35 Joint Strike Fighter, provides testimony to SCRAM usefulness:
“The SCRAM reviews were very collaborative…When we went forward with the results to our senior leadership, it was a jointly endorsed assessment. You gave us plenty of time to concur with your assessment or not. In short, we felt SCRAM was great.”
-William Urschel, F-35 Software Director, Joint Program Office (2012-2015)
The value of SCRAM has been validated by several complex, multi-phase programs requesting multiple SCRAM Reviews over a period of years at their cost and on their own initiative. In the words of one program staff member:
“We know when our program is going off the rails but we often don’t know why. The SCRAM Team can bring independent eyes to quickly identify why things are starting to go off track. That’s been very helpful for us.”
-Anonymous, Chief Engineer, System Program Office, Australian DoD
SCRAM Product Suite
The SCRAM Review method is supported by an extensive SCRAM Product suite including the SCRAM Schedule Risk Management Assessment Guide (best practices for each of the RCASS categories); a SCRAM Assessor Guidebook; Managing Schedule Risk training for all project staff and a SCRAM Assessor training and certification process that produces SCRAM Lead Assessors, Certified SCRAM Assessors and Provisional SCRAM Assessors.
SCRAM has also been extended to include a Manufacturing & Production (M&P) model extension to RCASS to assess schedule risk associated with the M&P aspects, including supply chain management, on a project.
The SCRAM Development Team is in the process of finalizing the Technical Implementation Risk Assessment (TIRA) taxonomy to assist projects in identifying the Technical Implementation Risk (as distinct from Technology Maturity Level risk) associated with implementing a specific technical solution with a specific set of contractor personnel and acquisition staff to meet a specific set of requirements and constraints.
Conclusion
SCRAM is a very effective method to determine a project’s ability to meet critical schedule milestones by identifying the root cause of issues and risks and quantifying their impact on schedule. It can be used to great effect by acquiring organizations to monitor their contractor’s ability to meet critical dates as well as by contractors themselves.
Further Information
For further information, please contact one of the SCRAM Principals
Government:
Adrian Pitman, Director of Project Performance Improvement. adrian.pitman@defence.gov.au
Commercial:
Angela Tuffley, Director RedBay Consulting. a.tuffley@redbay.com.au. (Australia, Asia Pacific)
Elizabeth (Betsy) Clark, President Software Metrics Inc. betsy@software-metrics.com (USA)
6.2 Siemens Teamcenter® PLM software embraces SysML and Integrates with Capella
Siemens announced on 22 August the new System Modeling Workbench for Teamcenter® software, built in partnership with Obeo, to extend Siemens’ model-based systems engineering (MBSE) offering. This solution will integrate the Teamcenter portfolio with both SysML general purpose modelling language for engineering and Capella, an open-source modeling tool dedicated to system, software and hardware architecture. Building on its extensive MBSE technology, Siemens PLM Software is further enriching the solution with a strong commitment to open-source software, enabling these technologies to integrate with the multi-domain digital twin.
For further information on System Modeling Workbench for Teamcenter, please see: https://www.plm.automation.siemens.com/global/en/products/collaboration/product-architecture.html
7. Systems Engineering Publications
7.1 Engineering Emergence: A Modeling and Simulation Approach
by
Larry B. Rainey and Mo Jamshidi
From the Amazon Website:
The book examines the nature of emergence in context of man-made (i.e. engineered) systems, in general, and system of systems engineering problems. It investigates emergence from a modeling and simulation perspective to interrogate or explore the domain space via modeling and simulation to facilitate understanding, detection, classification, and prediction of the phenomenon. Written by leading international experts, the text is the first to address emergence from an engineering perspective. It uses the discipline of modeling and simulation to explore the phenomenon of emergence found in man-made systems, in general, and system of systems engineering applications, specifically.
Format: Hardcover
Publisher: CRC Press; 1 edition (August 1, 2018)
ISBN-10: 1138046167
ISBN-13: 978-1138046160
7.2 Building High-Performance Project Talent — A Transformational Initiative
by
Canadian Department of National Defense
In an effort to develop strong, effective project managers, the Canadian Department of National Defense (DND) has created and implemented a comprehensive and robust program that aims to effectively develop and formally qualify all project managers to position the organization for ongoing project management success.
The DND’s Project Manager Competency Development (PMCD) framework was developed by a small, forward-thinking group of individuals within the department. They recognized the need to develop DND’s project management talent as well as more effectively match project managers’ competencies with the level of project complexity.
Through its efforts, the DND has made an investment to ensure that project management becomes a core competency that drives successful project outcomes. The PMCD framework’s ability to align project manager competencies with project complexities will continue to play a critical role in meeting the strategic objectives of the Federal Government’s major equipment recapitalization program for the Canadian Armed Forces and perhaps become a model of excellence for successful project management throughout the entire government.
Building high-performance, competent project talent requires a process that ensures employees have the technical skills they need for effective project management, as well as leadership, and strategic and business management acumen required to get the job done. In grooming the next generation of project managers, DND recognized the imperative of equipping its people to excel within a shifting project paradigm. While the original project management triple constraint is marked by time, cost and scope, DND’s PMCD framework focuses on a talent triangle of skills that includes:
- Technical (project management)
- Leadership (behavioral)
- Contextual (government/DND knowledge)
7.3 Systemic Change Management:
The Five Capabilities for Improving Enterprises
by
George L. Roth and Anthony J. DiBella
From the Amazon Website:
Achieving and sustaining great business performance requires more than ongoing internal improvements; it demands a capacity to promote changes across organizations that depend on one another. Through a series of cases, Systemic Change Management describes a systems approach to enterprise change. Organizations are more successful individually and collectively when they develop and diffuse five enterprise change capabilities – promoting enterprise awareness, installing innovation sets, balancing push and pull changes, seeking growth, and distributing leadership. Each capability enhances individual firm performance and when used together create a synergy that magnifies their overall effectiveness and impact.
This book explains how a system of change capabilities can be developed and demonstrates their use at a variety of organizations, including United Technologies, Rockwell Collins, Raytheon, Toyota, Ariens, the US Army, and US Air Force. The reader will come to understand that performance improvement requires internal change along with collaboration with suppliers and other organizations to effectively function as an enterprise.
Format: Kindle, Hardcover, Paperback
Publisher: Palgrave Macmillan; 2015 edition (April 16, 2015)
ISBN-10: 1137412011
ISBN-13: 978-1137412010
Editor’s Note: This book is rated five stars (out of 5) at Amazon. Note the comments of a reviewer: “As a former practitioner in Organizational Development and alliance relationships, I was curious what this book might offer that is new in systems change management. From the stories of NUMMI executives ‘closed eyes’ to the discussion of high performance relationships’ impact on the success of huge corporate networks, I was fascinated and captivated by this book. It is one of the best summarizations of systems thinking I have ever read, but goes well beyond theory. The hundreds of examples of successful organizational change offered in the book become a blueprint to inspire and rethink how to effectively create change within multiple environments, whether it be work, governing, social organizations, families and more. Unlike many academic approaches to systems thinking and theory, this book creates infinite possibilities for emerging leaders to learn and apply invaluable real life lessons.” Source: “Joan”, August 6, 2015.
Access review here.
7.4 Program Management (2nd edition)
by
Michel Thiry
From the Amazon Website:
Program management (PgM) is fast developing as the essential link between strategy and projects and as a vehicle for organizational change. It offers the means to manage groups of projects with a common business purpose in an integrated and effective way. The Second Edition of Michel Thiry’s Program Management builds on the bestselling title first published in 2010. The heavily revised text reflects the latest program management guides and international standards and includes: a new section on agile management in programs; the author’s own program management maturity measure; a new section on change management, which is now integral to many programs. Michel has also reviewed and revised the program lifecycle to align with the more unified view of program management that has emerged since the book was first published. The result is an essential guide to program management that incorporates a robust theoretical framework, complemented by examples and advice from one of the world’s leading practitioners.
Format: Kindle, Paperback
Publisher: Routledge; 2 edition (February 8, 2016)
ISBN-10: 1472474279
ISBN-13: 978-1472474278
Editor’s Note: This book is rated five stars (out of 5) at Amazon. Note the comments of a reviewer: I highly recommend Michel’s comprehensive book on program management. I studied the first edition back to back when preparing for my PMI PgMP certification and found Michel’s observations, recommendations and the thorough review of related tools, practices and context extremely helpful. I have recommended this book to peers and other organizational project management professionals more than any other book. I have enjoyed reviewing all the additions in this second edition just as much and in particular; welcome the new perspectives, observations and recommendations around agility and agile management in program management context. I also find Michel’s illustrations particularly valuable, and I have referred to them numerous times in my own work. Regarding the critically important matter of benefits realization, I applaud Michel for calling out the role of the Business Integrator (or Business Manager) in the actual and tangible benefits realization. Finally, anyone who is looking for either a comprehensive guide on program management, leading input and examples on specific critical program management tools or a pillar for your curriculum of the broader organizational project management you will without a doubt find top value and actionable insight here – like I did.
7.5 Don’t Jump to Solutions:
Thirteen Delusions that Undermine Strategic Thinking
by
William B. Rouse
From the Amazon Web site:
Strategic planning expert William Rouse cuts to the heart of the most common causes of failed business plans and strategies and shows how to overcome them. He encourages strategic thinkers and planners to spend much more time analyzing a situation instead of jumping to ready solutions. The tone is tongue-in-cheek, but the keen observations and sage advice Rouse offers aptly address a serious subject. It’s a fast-track primer in critical thinking and evaluation planners and managers at every level can use to approach their work more effectively.
Format: Kindle, Hardcover, Digital
Publisher: Jossey-Bass; 1st edition (January 23, 1998)
ISBN-10: 078790998X
ISBN-13: 978-0787909987
7.6 Journal of Change Management
Journal information
Aims
Routledge’s Journal of Change Management (JCM) was established as a community center for all scholars and practitioners with an interest in the complex and multidisciplinary field of organizational change, and its management and leadership. JCM publishes peer-reviewed case studies, reviews, conceptual contributions and empirical research of the highest quality. Being supported by a world leading editorial board we are committed to becoming the leading journal in our field. Although being a somewhat young journal, JCM has already been embraced by esteemed colleagues such as Dick Scott (Stanford University) and Karl E. Weick (University of Michigan), who have both published in our popular Reflections series.
Scope
Journal of Change Management is a multidisciplinary and international forum for critical, mainstream and alternative contributions – focusing as much on psychology, ethics, culture and behavior as on structure and process. JCM is a platform for open and challenging dialogue and a thorough critique of established as well as alternative practices. JCM is aiming to provide all authors with a first decision within six weeks of submission.
Print ISSN: 1469-7017 Online ISSN: 1479-1811
4 issues per year
Journal of Change Management is abstracted and indexed in:
ABI/Inform; Association of Business Schools (ABS); EBSCO (Advanced Placement Source ; Business Source Alumni Edition; Business Source Complete; Business Source Corporate; Business Source Premier; Current Abstracts; TOC Premier); Ergonomics Abstracts; OCLC; PsycINFO; Scopus; Swets Information Services; and Thomson Gale.
7.7 Engaging Stakeholders for Project Success
by
James Wilsdon, Robert Doubleday and James Hynard
PMI White Paper
From the White Paper:
This paper proposes an approach to stakeholder management that is broad in intent and scope. It identifies how engagement should work on projects and converts that new knowledge into realistic change management plans. This process is also a way of engaging people early on in any project. Project teams should be speaking with all stakeholders, obtaining viewpoints, and creating a set of actions as parts of the project plan that are informed by the true dynamics of the project.
Stakeholder management needs to focus more on engagement in order to move projects from installation to implementation. Stakeholder management needs to be less hierarchically focused and, at the same time, needs to take into account the fluid political nature of organizations. Projects should start with the premise that identifying a range of stakeholders and engaging with them in a consistent and organized manner will improve project success.
Sometimes stakeholder management processes have failed to take into account the dynamic nature of the stakeholders’ commitment to a project and the relationships between different stakeholders as a project progresses. By having project teams focused not only on their own stakeholder role, but also thinking about the other key stakeholders in a project and how they interact, project teams will find the edge they are looking for. There are three steps to achieving more effective stakeholder engagement:
1. Build the stakeholder map and maintain it as the project ebbs and flows.
2. Prioritize key stakeholders and frequently revisit assumptions about levels of commitment and influence.
3. Develop key stakeholders and build their commitment to the change.
The authors distinguish between an “installed” project and an “implemented” one:
Installed means that the solution (this can be the latest technology, new organizational structures, recent acquisitions or redesigned processes) is often in place, but the recipients of the change—where recipients are defined as the people directly or indirectly impacted by the change—haven’t changed their behaviors and habits sufficiently for the change to achieve the forecasted benefits. Implementation, on the other hand, is installation plus commitment and behavior change that is aligned to the new way of working. Stopping at installation rather than working toward implementation creates a value gap for the organization, since the benefit contribution from the project (and its inherent change) have not been fully realized.
Miller (2002) cites released data from Gartner research that indicated that for major corporate investments, 80% were not used as intended – or not at all – six months after installation.
Download available here.
8. Education and Academia
8.1 University of Southampton Hosts International Conference for Safety Critical Systems Software
Computer scientists promoted advances in the design and analysis of safety critical systems at the 6th international ABZ conference in Southampton. Dozens of experts from academia and industry gathered at Southampton’s Grand Harbor Hotel to cross-fertilize methods for systems such as cars, trains, and planes, where software failures would lead to loss of life or significant damage to businesses. The event, which was hosted by researchers in Electronics and Computer Science (ECS) at the University of Southampton, covered six related state-based and machine-based formal methods of software engineering.
The conference continued a tradition of defining an industrial case study that researchers could apply to their methods in order to compare the international approaches. The 2018 case study detailed a new European rail signaling system that aims to increase the volume of trains operating on lines while continuing to mitigate dangers such as collisions.
A joint keynote was delivered by Altran senior software engineers Janet Barnes and Angela Wallenburg, offering insights into the successes and challenges of deploying formal methods into industry.
The six formal methods discussed at the conference included Abstract State Machines (ASM), the B-Method and the Z notation – which form ABZ – along with Alloy, Temporal Logic of Actions (TLA), and the Vienna Development Method (VDM).
Professor Michael Butler, Program Committee Chair from ECS at Southampton, advised: “Our society’s increased reliance on software for control in systems such as transport means that methods for ensuring trustworthiness of software is essential. ECS is at the forefront of research and applications in this field and we are proud to have welcomed experts from across the globe to this international conference. The quality of papers and presentations has been very high and it’s been great to see the strong level of engagement between attendees.”
Michael’s research at Southampton encompasses applications, tools, and methodology for formal methods, in particular one model-based method called Event-B. His key theoretical and methodological contributions have enabled the method to scale to large complex systems.
9. Some Systems Engineering-Relevant Websites
ProjectManagement.Com
A one-stop shop for answering questions related to Project Management that deal with project management challenges with confidence. Website contains over 11 000 articles, 1 000 templates and 550 000 peer connections for expert advice. Other features include tools and training directories, technique repository and PM Prep questions to help visitors to the site better prepare for certification.
Technology Innovation Management Review
The Technology Innovation Management Review (TIM Review) provides useful content about the issues and emerging trends that are relevant to launching and growing a technology business. The TIM Review focuses on theories, suggestions and tools that will help technology companies of varying size. This particular link directs to an article proposing a Method and Tool to Support Management of Systems Engineering Projects by aligning practices of systems engineering and project management for quick and efficient system development.
https://timreview.ca/article/878
Evolved Analytics – Model Building Lifecycle
Link to an article on the Evolved Analytics website about the Model Building Lifecyle that describes the process of converting data to information and then to knowledge and finally to understanding. The write-up describes how the onus for extraction of wisdom from a model lies with the user and that the underlying system will almost always change over time. These changes ought to be captured in terms of parameters to avoid decay of accuracy of the model overtime.
http://evolved-analytics.com/?q=support/learning/modeling/modelLifeCycle
NCBI – The Tools of Systems Engineering
A link to the full contents of Chapter 3 in Building a Better Delivery System: A New Engineering/Health Care Partnership on The Tools of Systems Engineering. The chapter, through making use of specific examples in the health care industry, describes how timely collection of data, analysis, and sharing of process and outcome data would benefit all stakeholders in an organization. The chapter describes how communications systems are critical to effectiveness of existing and emerging systems-design, -analysis and control tools in order to transform systems. The article discusses systems-design tools such as Quality Functional Deployment (QFD), systems-analysis tools such as discrete-event simulation and systems-control tools such as Statistical Process Control (SPC) tools.
https://www.ncbi.nlm.nih.gov/books/NBK22835/
10. Standards and Guides
10.1 ISO/IEC 33001 Updates ISO/IEC 15504 Series
Taken from the Standards Forum and Document Center websites
ISO/IEC 33001:2015 provides a repository for key terminology relating to process assessment. It gives overall information on the concepts of process assessment, the application of process assessment for evaluating the achievement of process quality characteristics, and the application of the results of process assessment to the conduct of process management. ISO/IEC 33001:2015 provides an introduction to the ISO/IEC 330xx family of standards for process assessment; it describes how the parts of the family of standards for process assessment fit together and provides guidance for their selection and use. It explains the requirements contained within the suite and their applicability to performing assessments.
The ISO/IEC 33001 standard was released in 2015, representing the first step in moving the ISO/IEC 15504 series over to the new ISO/IEC 33000 numbering scheme. There’s a total of five new publications in the set. This is a complete technical and conceptual overhaul of the series on process assessment and offers users both inside and outside of the IT community an in-depth review of the topic. It is part of the SPICE (Software Process Improvement and Capability Determination) initiative. It can be used by both software developing organizations and by those who outsource such services. One thing to note is that all publications in this new series are first releases but are numbered as 2nd Editions.
ISO/IEC 33001, 2nd Edition, “Information technology – Process assessment – Concepts and terminology”
This is the overview document, directly replacing all of ISO/IEC 15504-1 and clauses 3 and 4.1 of ISO/IEC 15504-7. It provides you with the usual scope and referenced documents sections, then an extensive definitions clause 3 covers processes, process management, process assessment and process modeling terms. Following this, clause 4 gives you a review of the structure of the new ISO/IEC 33000 series of standards, and clause 5 discusses the concepts involved for process assessment of any kind.
The last three clauses cover the concepts of assessment of process capability, of conformance, and of conformity assessment. It also includes an annex with a table showing the relationship between the old series and the new. It is an exceptional review of the topic of this tool for process improvement.
ISO/IEC 33002, 2nd Edition, “Information technology – Process assessment – Requirements for performing process assessment”
The update replaces specific clauses of both ISO/IEC 15504-2 and ISO/IEC 15504-7. It addresses the concept of assessment itself, providing the user with requirements to achieve objective, repeatable, and consistent results. It also gives you information on the various classes of assessment (1, 2, and 3). Annex A includes a table with information on the categories of independence of bodies and personnel who perform an assessment. And Annex B provides you with example content that might be included in an assessment report.
ISO/IEC 33003, 2nd Edition, “Information technology – Process assessment – Requirements for process measurement frameworks”
ISO/IEC 33003 also replaces parts of ISO/IEC 15504-2 and ISO/IEC 15504-7. It is a requirements standard, giving you the tools to set up a measurement framework for each process quality characteristic. You will do this by defining a set of process attributes for each.
The standard takes you through conceptualization, construct definition, operationalization, construct specification examination, rating process attributes, aggregation, and sensitivity analysis. Then it covers the requirements for validating and verifying conformity for these frameworks. Annexes cover a terminology map, reflective or formative construction specification, statistical validation methods, and how to implement the requirements for process measurement frameworks. Finally, a 45item bibliography completes the document.
ISO/IEC 33004, 2nd Edition, “Information technology — Process assessment — Requirements for process reference, process assessment and maturity models”
Again, we have a partial replacement of the 15504 Parts 2 and 7. This time we’re reviewing the modeling requirements involved. The standard covers process reference models, process assessment models, and maturity models. It concludes with a 3-item bibliography.
ISO/IEC 33020, 2nd Edition, “Information technology — Process assessment — Process measurement framework for assessment of process capability”
The new ISO/IEC 33020 cancels and replaces the clause 5 of ISO/IEC 15504-2. Here we have the document that provides you with the requirements for measuring your process capability in accordance with ISO/IEC 33003. You will use it to confirm that the process you use is able to consistently meet current or projected business goals.
The standard is composed of the usual scope, referenced documents, and definition sections. An overview of the topic follows. Then there is extensive coverage of the process measurement framework, including various process capability levels and process attribute rating methods. Annex A reviews the conformity issue, with references to the ISO/IEC 33003. Annex B gives you an example of a process performance model. A 7-item bibliography completes the document.
Copies of these standards may be obtained at the Document Center Inc. webstore, here. Copies are available in paper format or for pdf download. If you’d like more information or would like multi-user access, contact the Document Center by phone (650-591-7600), fax (650-591-7617) or email (info@document-center.com).
11. Some definitions to close on
11.1 Change Management
Source: Wikipedia
Change Management (CM) refers to any approach to transitioning individuals, teams, and organizations using methods intended to re-direct the use of resources, business process, budget allocations, or other modes of operation that significantly reshape a company or organization. Organizational Change Management (OCM) considers the full organization and what needs to change.
11.2 Key Stakeholder Management Definitions
Source: Miller, David, and Mike Oliver. Engaging Stakeholders for Project Success. PMI White Paper available at http://www.gbd.dk/files/984_engagingstakeholders.pdf
There is little agreement in the literature regarding the terms and definitions used for the various stakeholders associated with a project. The definitions used in this paper are taken from Managing Change in Organizations: A Practice Guide (PMI, 2013a), which include:
- Stakeholder: An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
- Stakeholder Management: The stakeholder management plan is a subsidiary plan of the project management plan that defines the processes, procedures, tools, and techniques to effectively engage stakeholders in project decisions and execution based on the analysis of their needs, interests, and potential impact.
- Agent: Active proponent(s) and driver(s) of the change.
- Lead: The lead function supports the overall change management process and implementation, including coordination of associated work streams within the scope of the project.
- Recipient: A person directly or indirectly impacted by a change.
- Sponsor: A person or group who provides resources and support for the project, program or portfolio, and is accountable for enabling success.
Additional definitions not found in Managing Change in Organizations (PMI, 2013a) or the PMI Lexicon of Project Management Terms (PMI, 2012) include:
- Sustaining Sponsors: In the paper The Sponsor as the Face of Organizational Change (Harrington & Nelson, 2013), the authors refer to the need for sustaining sponsors and state:
A top-down change project begins with the executive sponsor promoting the project. Acceptance and support of the change by all of the stakeholders, including those who may not have direct contact with the executive sponsor, is important. To accomplish this, the executive sponsor should enlist the help of the mid-level managers who have the power to legitimize the change with first-level managers. Once the mid-level managers are on board, they engage the first-level managers and communicate the purpose and value of the change. The buy-in from first-level managers allows them to become sponsors of the change to their teams. Engaging lower-level managers does not transfer accountability, but is a delegation of responsibility for portions of the sponsorship activities…Accountability then flows up from the first-level managers through the mid-level managers with the executive sponsor retaining ultimate accountability for the project and benefits realization (pp. 6–7).
The sponsor role is the most critical leadership role in predicting the success of organizational change. When sponsorship is done well, organizations see:
- Clear accountability for, and line of sight to, the change benefits;
- Legitimate reasons for people to engage in change;
- A clear sense of commitment to the new ways of working; and
- Active support for difficult decisions that often need to be made during major change.
- Stakeholder Potential: It is very important in stakeholder management to identify and help develop people to fulfill their specific stakeholder responsibilities. For example, many sustaining sponsors start out as recipients supporting the change and their sponsorship needs to be built over time. So, project teams should identify stakeholders for their potential rather than just their current pre-disposition.
- Change Networks: Change networks (see Figure) represent the flow of power and communication through the organization. A stakeholder map describes the way in which stakeholders actually interact with each other.
Figure 1: Change Network Representation
11.3 Basic and Fundamental Definitions for Use in the
Practice of Enterprise Architecture
by
Marc H Gewertz
President, EIM Consultants LLC
August 1, 2018
In the current void of specific industry standard definitions for the practice of EA, special care and attention has been taken to make best use of existing definitions established by industry standards (e.g., ISO-42010, “Systems and Software Engineering — Architecture Description”), to preclude the inclusion of organization-specific and industry-buzzword terminology and practices, and most especially, to preclude my personal terminology preferences and practices. These constraints were specifically invoked to allow, enable, assure and promote standard definition of the most basic and fundamental capabilities all businesses require to function regardless of the business domain, the size of the business, whether the business is for profit or non-profit, or the specific goods or services the business delivers.
The problem with most EA definitions is they are way beyond basic and fundamental, beginning at a level of context that is already down in the details.
The following definitions are a ‘homogenization’ of definitions and context. In every case they begin with definitions from dictionaries (multiple dictionaries, Google, and Bing) choosing among those versions that ‘fit’ a business context, and then ‘weaved’, together with my embellishments, based-on my experience, to arrive at a basic and fundamental definition, placed in the context of doing business, the starting point for use in EA.
In other words, the definitions are an ‘averaged’ dictionary definition placed into the context of the practice of EA (in the context of being able to be used in the description of a business situation). The definitions in Wikipedia, text books, graduate course materials, lectures, and other resources were used as a ‘sanity check’, to ensure that the definitions agree with the known usages of the terms.
It should be noted, in most cases, it is more a matter of the specific definitions in use by the community of practitioners ‘fit’ within the ‘boundaries’ of this definition. It is not a matter of ‘matching’ as these definitions are very wide and broad, being basic and fundamental, and the definitions of others already being specific and detailed.
Because all definitions ‘fit within’ this definition, this definition is very good at pointing out the commonality of what otherwise seem like non-common definitions that people argue about, miscommunicate, and misunderstand.
The basic and fundamental terms for use in communicating enterprise architecture practices are the following:
- Enterprise – a collection of people, process, information, technology, and other resources capable of realizing a value-added ability to satisfy a customer-based need, in order to accomplish the goal of serving the enterprise mission and sustaining the existence of the enterprise.
- Resource – a ‘thing of value’ to the workings of the enterprise, a source or supply from which value-adding benefit is produced for the enterprise. Examples of resources are workers, customers, suppliers, procedures, business information, technologies, patents, property, parts, materials, products, business plans, analyses, reports, reviews, contracts, subcontracts, sales, schedules, money, metrics, awards, rewards, and certifications.
- Offerings and Capabilities – collections of people, process, information, technology, and other enterprise system resources (“resources”) which together function to realize a value-added ability to satisfy a customer-based need, in order to accomplish the goal of serving the enterprise mission and sustaining the existence of the enterprise system.
- Capabilities are realized to meet the specific needs of the internal environment, to enable and assure the realization of offerings to the external environment, and to serve the collective goal of the enterprise.
- Offerings are capabilities provided to serve the specific needs of customers in the external environment and to meet the collective goal of the enterprise.
- Enterprise Capability – a formal collection of people, process, information, technology, and other resources which together function to realize an ability to satisfy the need to control the static and dynamic behavior of the enterprise system through governance, organization, integration, compliance, assurance, and enterprise management.
- Governance – the way enterprise abilities, resources and activities are controlled.
- Organization – the way enterprise capabilities, resources and activities are arranged, ordered, and assigned organizational ownership, authorities, and responsibilities.
- Integration – the way offerings, capabilities, resources, and activities are connected, combined, and coordinated into a unified whole.
- Compliance – the way of demonstrating enterprise capabilities, resources, and activities conform in fulfilling control requirements.
- Assurance – the way of being sure, certain, and confident that enterprise capabilities, resources, and activities demonstrate compliance.
- Enterprise Management – the way of conducting and controlling the business, process, insight, and IT capabilities, system and service offerings, resources, and activities of the enterprise.
- Business Capability – a formal collection of people, process, information, technology, and other resources which together function to realize an ability to satisfy the need for conducting business through mission, markets, portfolio, talent, operations, and business management.
- Mission – the way vision, purpose, and objective are pre-established and imposed.
- Markets – sources of supply and demand in the external working environment where resources, offerings, and capabilities are bought, sold and traded.
- Portfolio – a collection of offerings and capabilities owned, offered by, and/or supplied to the enterprise.
- Talent – the specific skills, abilities, knowledge, and experience workers need to properly perform a specific set of activities.
- Operations – the specific functional activities needed to realize offerings and capabilities.
- Business Management – the way of conducting and controlling the business capability, resources, and activities.
- Process Capability – a formal collection of people, process, information, technology, and other resources which together function to realize an ability to satisfy the need for understanding, defining, and communicating work activities through policy, procedure, roles, workflow, process improvement, and process management.
- Policy – a specification of governance through a set of high-level control requirements defining a definite course and method of action to guide and determine present and future decisions including the need for and content of procedure.
- Procedure – the specification of a series of actions to be accomplished in a specific way or order and acceptable behaviors, outcomes, and results in compliance with policy requirements.
- Roles – the functional responsibilities workers have in specific activities and situations related to process capability.
- Workflow – the smooth and continuous movement of work activities, resources, and work products in the direction of realizing offerings and capabilities.
- Process Improvement – a way to optimize business processes to achieve more efficient and effective results.
- Process Management – the way of conducting and controlling the process capability, resources, and activities.
- Insight Capability – a formal collection of people, process, information, technology, and other resources which together function to realize an ability to satisfy the need for an ability to learn, understand, communicate, and apply what is explicitly known through data, information, configurations, records, knowledge, and insight management.
- Data – Within the context of an enterprise, a structured, processed, and defined collection of numbers and characters.
- Information – Within the context of an enterprise, structured, processed and defined collections of data placed into a context.
- Configurations – processed results and arrangements of data, information, materials, parts, assemblies and other things placed into a context for a specific use.
- Records – stored configurations of data, information, and configurations for reproduction, use, measurement, indication, and evidence in the future.
- Knowledge – an awareness of stored configurations of data and information produced, used, measured, indicated and communicated in the past and intended for reuse in the future.
- Insight Management – the way of conducting and controlling the insight capability, resources, and activities.
- IT Capability – a formal collection of people, process, information, technology, and other resources which together function to realize an ability to satisfy the need for Information Technology (IT) products, systems, and services through communication technologies, IT applications, IT infrastructure, information utilization, procured IT services, and IT management.
- Communications Technologies – equipment transmitting, emitting, or receiving signs, signals, writings, images, and sounds or insight of any nature by wire, radio, optical, or other electromagnetic systems, products, or other mediums of communication.
- IT Applications – computer software designed to help users to perform specific tasks.
- IT Infrastructure – a combined set of hardware, software, networks, facilities, etc. (including all of the information technology), in order to develop, test, deploy, operate, monitor, control, maintain, and support the delivery of IT services.
- Information Utilization – the processing of data and information within the IT network, systems, and applications.
- Procured IT Services – IT capabilities made available to the enterprise as a service from a supplier.
- IT Management – the way of conducting and controlling the IT capability, resources, and activities.
- System Offering – a formal collection of people, process, information, technology, and other resources which together function to realize an ability to satisfy the need for technology goods, products, or systems for a customer through system needs, system requirements, system products, system solution, system abilities, and system management.
- System Needs – those things concerning the system offering that are necessary for the system to accomplish its purpose, add value, and satisfy the stakeholders in the system offering.
- System Requirements – those things concerning the system that are necessary for the development and operation of the system.
- System Products – the hardware, software, data, and service elements used in the system solution. The use of system products is defined by the system architecture and associated system specifications. System products (and goods) are defined by their product architectures and associated product specifications.
- System Solution – the way the system, products, and goods are designed, developed, implemented, integrated, verified, deployed, operated, and sustained.
- System Abilities – the way the system, products and goods are validated, used, and maintained.
- System Management – the way of conducting and controlling the system offering, resources, and activities.
- Service Offering – a formal collection of people, process, information, technology, and other resources which together function to realize an ability to satisfy the need for services for a customer through service needs, service requirements, service catalog, service solution, service abilities, and service management.
- Service Needs – those things concerning the service offering that are necessary for the service to accomplish its purpose, add value, and satisfy the stakeholders in the service offering.
- Service Requirements – those things concerning the service that are necessary for the development and delivery of the service.
- Service Catalog – the service elements used in the service solution. The use of service elements is defined by the service architecture and associated service specifications. Service elements are defined by their service element architectures and associated service element specifications.
- Service Solution – the way the service is designed, developed, implemented, integrated, verified, deployed, delivered, and sustained.
- Service Abilities – the way the service is validated, used, and sustained.
- Service Management – the way of conducting and controlling the service offering, resources, and activities.
12. Conferences and Meetings
For more information on systems engineering related conferences and meetings, please proceed to our website.
13. PPI and CTI News
PPI and INCOSE Sign Memorandum of Understanding
Project Performance International (PPI) and The International Council of Systems Engineering (INCOSE) have executed a Memorandum of Understanding (MoU) to collaborate in professional areas of mutual interest, to the benefit of the practice of systems engineering. Short term initiatives include:
- joint development and operation of an on-line systems engineering tools database providing free access by INCOSE members and PPI clients to systems engineering tools data; and
- free access by INCOSE members to PPI’s Systems Engineering Goldmine (SEG). The SEG is a curated archive of currently 4GB+ of downloadable systems engineering documents and a searchable database of 7800+ defined terms used in, or relevant to, systems engineering.
PPI’s Managing Director, Mr. Robert Halligan FIE Aust CPEng IntPE(Aus) said; “This collaboration between PPI and INCOSE is a significant step towards PPI’s vision of all engineers worldwide practicing systems engineering, as the way that engineering is done. We at PPI look forward with excitement to working even more closely with INCOSE in the future, to the benefit of humankind.”
A Framework of Knowledge, Skills and Attitudes Conducive to High Performance Engineering
PPI leaders when travelling frequently deliver free evening presentations to professional societies. The latest on offer, available from October 23rd, has the title above, and the synopsis below.
Engineering projects are notoriously challenging, even more so for projects that are ground-breaking, complex and critically important. We are all trying to do these projects well, and to do them better- which drives the topic of this presentation.
Engineering is a team sport. And like football, the performance of the team is governed by the knowledge, the skills and the attitudes (KSAs) of the team members. The KSAs for engineering relate to the traditional engineering streams of technology, mathematics and physics, the systems engineering stream of knowing how to go about applying the technology, mathematics and physics in a way conducive to success, and the soft skills such as communication and emotional intelligence, skills that distinguish a team from just a mob.
A variety of engineering competency frameworks exists. In this presentation, we overview existing systems engineering competency frameworks. We then present a new, recommended framework; new in terms of publication but old in that it has been the foundation of the systems engineering education of over 13,000 engineers worldwide. This recommended framework exhibits a strong alignment with, we believe, practical, in-the-trenches, efficient, value-driven, high-performance engineering.
14. PPI and CTI Events
On-site systems engineering training is being delivered worldwide throughout the year. An overview of public courses is below. For a full public training course schedule, please visit https://www.ppi-int.com/course-schedule/
Systems Engineering 5-Day Courses
Upcoming locations include:
- London, United Kingdom
- Sydney, Australia
Requirements Analysis and Specification Writing 5-Day Courses
Upcoming locations include:
- Pretoria, South Africa
- Wellington, New Zealand
Systems Engineering Management 5-Day Courses
- Upcoming locations include:
- Ankara, Turkey
- Münich, Germany
Requirements, OCD and CONOPS in Military Capability Development 5-Day Courses
Upcoming locations include:
- Amsterdam, the Netherlands
- Washington, D.C., United States of America
Architectural Design 5-Day Course
Upcoming locations include:
- Melbourne, Australia
- London, United Kingdom
CSEP Preparation 5-Day Courses (Presented by Certification Training International, a PPI company)
Upcoming locations include:
- Laurel, MD, United States of America
- Madrid, Spain
Other training courses available on-site only includes:
- Project Risk and Opportunity Management 3-Day
- Managing Technical Projects 2-Day
- Integrated Product Teams 2-Day
- Software Engineering 5-Day.
15. Upcoming PPI Participation in Professional Conferences
PPI will be participating in the following upcoming events. We support the events that we are sponsoring and look forward to meeting old friends and making new friends at the events at which we will be exhibiting.
SWISSED
(Sponsoring)
Date: 3 September 2018
Location: Zurich, Switzerland
(Exhibiting)
Date: 4 – 6 September 2018
Location: Adelaide, Australia
INCOSE Western States Regional Conference
(Sponsoring)
Date: 20 – 22 September 2018
Location: Ogden, Utah, USA
4th IEEE Symposium on Systems Engineering
(Sponsoring)
Date: 1 – 3 October 2018
Location: Rome, Italy
(Exhibiting & Sponsoring)
Date: 3 – 5 October 2018
Location: Pretoria, South Africa
INCOSE Great Lakes Regional Conference
(Sponsoring)
Date: 17 – 20 October 2018
Location: Indianapolis, IN, USA
(Exhibiting)
Date: 22-26 October 2018
Location: Cleveland, OH, USA
New Zealand Defence, Industry & National Security Forum
(Exhibiting)
Date: 31 October – 1 November 2018
Location: Palmerston North, New Zealand
The INCOSE International Symposium 2019
(Exhibiting)
Date: July 2019
Location: Orlando, USA
The INCOSE International Symposium 2020
(Exhibiting)
Date;18-23 July 2020
Cape Town, South Africa
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com
Ralph Young, Editor, email: ryoung@ppi-int.com
René King, Managing Editor, email: rking@ppi-int.com
Project Performance International
2 Parkgate Drive, Ringwood North, Vic 3134 Australia
Tel: +61 3 9876 7345
Fax: +61 3 9876 2664
Tel Brasil: +55 12 9 9780 3490
Tel UK: +44 20 3608 6754
Tel USA: +1 888 772 5174
Tel China: +86 188 5117 2867
Web: www.ppi-int.com
Email: contact@ppi-int.com
Copyright 2012-2018 Project Performance (Australia) Pty Ltd, trading as Project Performance International.
Tell us what you think of PPI SyEN. Email us at syen@ppi-int.info.
- The collective term Systems Engineering Professional (SEP) covers ASEP, CSEP, and ESEP designations. There is a hierarchy: ASEP is an introductory level for those new to the discipline. CSEP is for “typical” Practitioners, and ESEP is targeted at experienced professionals, specialists, and experts within the discipline. ↑
- This legislation is applicable across the whole of the European Union (EU), although as with all EU legislation, each country is responsible for integrating it within its own legal system. In the UK, the Equality Act 2010 includes provisions that ban age discrimination against adults in the provision of services and public functions. The ban came into force on 1 October 2012, and it is now unlawful to discriminate based on age unless the practice is covered by an exception from the ban. Note that this includes both direct and indirect discrimination (the latter being when a good or service has criteria which have the effect of being discriminatory against a person because of a protected characteristic such as their age.). See www.ageuk.org.uk for more information. ↑
- As of 2017 these areas were defined by the CAG as “Requirements Engineering”, “System and Design Analysis”, “Architecture Design/Development”, “System Integration”, “Verification and Validation”, “Technical Planning”, “Technical Monitoring and Control”, “Risk and Opportunity Management”, “Information and Configuration Management”, “Lifecycle Process Definition and Management”, “Acquisition and Supply”, “Speciality Engineering”,” System Operation and Maintenance”, “Organizational Project Enabling Activities” and “Other”. The area called “other” is there primarily to allow individuals to document systems engineering experience which they feel unable to fit within any of the other 14 areas. ↑
- This last circumstance was tested in the UK Ministry of Defence (MoD) in 2017 and was part of the primary rationale for commencing the competence-based pilot in the UK Chapter. ↑
- In fact, there is some discretion within the review team in this area, but in principle 60 months is OK and 59 months is Not OK as it’s easy to confirm compliance. ↑
- As with overall duration there is reviewer discretion, but in principle 12 months = OK, 11 months = Not OK as it’s easy to confirm CSEP rule compliance ↑
- For example, if an applicant refers to a period of experience as “Requirements Elicitation” but the reference refers the same period as “Technical Planning” are they referring to the same activity or not? Is the candidate being inaccurate in their disclosure, or is the reference misinformed? Or is this simply a difference in viewpoint for the same activity? ↑
- This is acknowledged within the INCOSE ESEP program which includes a mandatory verbal interview with applicants and an interview with references. ↑
- As a comparison, when assessing skills for employment, it is rare for an employer to take on a new permanent employee without a face-to-face interview even if their CV/Résumé and references look fine. The same rationale can be applied to assessment of competence for Certification. ↑
- A mapping was performed by the author when a member of the INCOSE Certification Advisory Group. The mapping is not perfect, since neither the INCOSE nor the INCOSE UK viewpoint is 100% complete or correct. Nevertheless, a mapping is possible. ↑
- An “open” question does not have a defined “Yes” or “No” answer. Open questions provide an opportunity for the interviewer to ask supplementary questions based upon the response. As an example, “Have you talked to all stakeholders?” compares with “Which stakeholders have you talked to?”. The latter requires more thought from the candidate and may expose weaknesses in the candidate’s capability. ↑
- The new INCOSE Competency Framework is freely available for download from the INCOSE website. ↑
- This was suggested as a further way of improving and standardising the breadth profile of applicants. The pilot was used as a test-bed for this assumption. ↑
- Assessors were selected from a pool of existing INCOSE CARs, but were also required to demonstrate experience in performing competence-based interviewing using the INCOSE SE Competency Framework. ↑
- Pilot candidates were still required to take and pass the standard CSEP Knowledge Examination to be formally designated “CSEP”. ↑
- Although the pilot did not produce any disagreements, the principle would be a referral for candidates where assessors could not agree. ↑
- Indeed, having participated in or overseen many competence-based assessments, the author’s experience is that the ability to question a candidate usually means that in practice there is little divergence between interviewer assessments. ↑
- This URL ink was broken at time of press. The INCOSE Certification office has been contacted for an alternative source of information for the history of the Certification Program. If an alternative source Is identified, this information will be included in a relevant section in the next edition of PPI SyEN. ↑
- Harrington, H. James, Frank Voehl, and Christopher F. Voehl, Model for Sustainable Change, Program Management Institute, 2015. White Paper available at https://www.pmi.org/learning/library/model-sustainable-change-11122 ↑
- Nightingale, Deborah, and Jayakanth Srinivasan. Beyond the Lean Revolution: Achieving and Sustaining Successful Enterprise Transformation. New York: AMACOM Press, 2011. Available at https://www.amazon.com/Beyond-Lean-Revolution-Sustainable-Transformation/dp/0814417094/ref=sr_1_fkmr0_1?s=books&ie=UTF8&qid=1529442068&sr=1-1-fkmr0&keywords=Beyond+the+Lean+Enterprise%3A+Achieving+and+Sustaining+Successful+Enterprise+Transformation ↑
- Ibid. ↑
- Available at https://www.ppi-int.com/wp-content/uploads/2018/01/SyEN_61.pdf ↑
- McKinney, D., E. Arnold, and Sarah Sheard, “Change Agency for Systems Engineers”. INCOSE International Symposium. 25(1), 1209-1231, 2015. The authors identify characteristics of an effective change agent and summarize their findings in three dimensions: philosophy, knowledge, and skills. One of the key skills is systems thinking. ↑
- Combe, Marge. Change Readiness: Focusing Change Management Where it Counts. White Paper available at https://www.pmi.org/learning/library/change-readiness-11126 ↑
- Conforto, E. C., M. Rossi, Eric Rebentisch, J. Oehmen, and M. Pacenza. Survey Report: Improving Integration of Program Management and Systems Engineering: Results of a Joint Survey by PMI and INCOSE, Presented at the 23rd INCOSE Annual International Symposium, Philadelphia, Pennsylvania USA, June 2013. Available at https://www.pmi.org/learning/library?q=Survey+Report%3A+Improving+Integration+of+Program+Management+and+Systems+Engineering[↑
- IBM. Making Change Work: Continuing the Enterprise of the Future Conversation. Armonk, NY: International Business Machines Corporation. Available at http://www-935.ibm.com/services/us/gbs/bus/pdf/gbe03100-usen-03-making-change-work.pdf.The document provides a list of questions that facilitate identification of your organization’s current change readiness status; and encourages one to look for patterns in the responses that prioritize improvement opportunities. The report concludes that companies can no longer justify or afford an ad hoc approach to change management ↑
- Gartner is a leading information technology research and advisory company, see website here. ↑
