Advanced Information Systems Analysis and Design: Class 10: New Directions in Software Development

Advanced Information Systems
Analysis and Design

Class 10: New Directions in
Software Development
Alan R. Hevner
University of South Florida
October 25, 2018 Copyright 2018 Alan Hevner 1

Class 10 Outline
 The Cloud
 Cloud Computing
 Industry Clouds
 Research Directions in the Cloud
 The Future of the Cloud
 Flow-Service-Quality Methods of Specification and Design
 Internet of Things Software Development
 Intellectual Control of IoT Systems
 Semantics (Flow, Quality, Evolution)
 Smart City Example
 Platform-based Software Development
 Effectual Software Development on Platforms
 Research Contributions and Future Directions
Cloud Computing
 Computing as a Utility (e.g. electricity, water)
 Key characteristics:
 The illusion of infinite computer resources available
on demand
 The elimination of an up-front commitment by
Cloud users
 The ability to pay for use of computing resources
on a short-term basis as needed
 Cloud Computing changes the economic
equations of systems development and use

The Move to the AAS (As A Service)
Paradigm
 "Think of what Salesforce.com did to CRM. Now,
imagine if the same thing were to occur in the ERP
market - it would be huge…
 A lot of the industry standard business functions can

move to BPaaS and custom business functions could
move to IaaS. With a shift like that, we could see a day
where businesses might not own or manage any IT
assets."
 Head of Syntel's Cloud Computing Center of Excellence
4 October 25, 2018 Copyright 2018 Alan Hevner

Current Paradigms
 Software as a Service (SaaS)
 e.g. Web-hosted applications
 “Consume”
 Platform as a Service (PaaS)
 Developer tools to build apps
 “Build”
 Infrastructure as a Service (IaaS)
 Hardware, computing and telecommunications
 “Host”
 Public/Private Cloud
 Consume, build, host analogies
 http://silverlighthack.com/post/2011/02/27/IaaS-PaaS-and-SaaS-Terms-
Explained-and-Defined.aspx
 These paradigms focus often on where something is done
(public/private) and what services are offered (i.e. software, hosting etc).

Cloud Themes
 Mobile Computing is made for the Cloud
 Mobile extends the footprint and reach of the Cloud
 Cloud Interoperability
 Major alliances are working on Cloud standards for
integration of offerings
 The Future is in the Cloud
 Allmajor SW markets have Cloud products
 Integration of local apps with Cloud apps
 Security as a Service
 Trust in the AAS delivery models is growing

Cloud Themes Continued
 Intelligent Networks
 Cloud requires a complex networking infrastructure that
leverages virtualization across multiple servers and data
centers
 Faster connectivity and Mega-bandwidth demand
 Application and Location aware
 Collaboration and Social Networks
 Exploit the promise of social network apps
 Platform Proliferation
 Rapid growth in integrated platforms
 Private Clouds
 Where do private clouds and public clouds meet?

A Proposed Cloud Framework
 Is based on strategic and tactical choices that organizations need to make as
they embrace the cloud
 e.g. ‘How much of our data should be in the cloud?’
 To effectively capture this organizational decision-making, we propose a six-

dimensional framework with a sliding scale of distribution between internal and
external (cloud) locations.
 The dimensions are:

 Applications: Executable software in the form of services
 Data: Data in the form of files, databases, data repositories, data warehouses, etc.
 Computing: Processing resources
 Storage: Storage resources
 Networking: Communication and transmission resources
 Human Capital: Human resources

Cloud Computing Framework

Choice of Controls
 Organization often also make a choice of how much local
control is needed within each of the six dimensions
 An organization might for instance choose to have high

control on storage infrastructure on the cloud but low
control on the human capital dimension
 Thus, each dimension has a separate ‘control knob’ to

denote the amount of control the organization wishes to
retain on that dimension regardless of its distribution on
the cloud

Exemplars of Cloud Architectures
Apps Data Comp Storage Netwk HC Description
100% 100% 100% 100% 50% 80% An organization that outsources significant IS work, uses Software as a
High High High High High Low Service (SaaS) model, but in a “private cloud” setting (as shown by the
high degrees of control required for these dimensions.)
50% 100% 50% 100% 50% 80% An organization that maintains its own offshore division (high degree of
Low Low Low Low Low High control to the human capital that is external), uses an AJAX-like
architecture where there is a combination of execution in the cloud as
well as locally, but in a “public cloud” setting (as shown by the low
degrees of control)
0% 0% 0% 0% 50% 100% An organization that builds its own data analytics models internally in an
H H H H H H offshore location, but uses the cloud for deployment. The organization
100% 100% 100% 100% 100% 100% has two distinct configurations corresponding to stages in the lifecycle.
L L L L L L The first two rows represent choices in the model building component;
the last two are for deployment. While these can be combined using a
composite score, this detail provides a richer view (e.g. user of
Zementis).
100% 100% 100% 100% 100% 0% An organization that provides hosting, analytics, and advertising
L H L H L H optimization in the cloud, but which uses the public cloud for all aspects
of its development except for dedicated database servers on the cloud
with high control for data and storage (e.g. SiteWit.com).
0% 0% 100% 100% 75% 0% An organization that provides a proprietary hurricane simulation for
H H L L L H weather applications, which requires supercomputer-level resources
obtainable via the cloud (using application and data replication for
execution akin to Google’s MapReduce).

Top 10 Obstacles/Opportunities
(Berkeley Report)
1. Availability of a Service
2. Data Lock-In
3. Data Confidentiality and Auditability
4. Data Transfer Bottlenecks
5. Performance Unpredictability
Copyright 2018 Alan Hevner October 25, 2018 12

Top 10 Obstacles/Opportunities
(Continued)
6. Scalable Storage
7. Bugs in Large-Scale Distributed Systems
8. Scaling Quickly
9. Reputation Fate Sharing
10. Software Licensing
Copyright 2018 Alan Hevner October 25, 2018

13
Technical Research Challenges
 Design of Business Transactions
 New and effective modeling theories and tools
 Parallel Processing and Coordination

 Buildingapplications to take advantage of cloud
resources
 Analytics on the Cloud

 Business intelligence via the cloud

FSQ Systems Engineering
 Network-centric system realities: complexity and survivability challenges
 Boundaryless systems with shifting connectivity
 Systems-of-systems integration, uncertain COTS function and quality
 Unpredictable failures, disruptions, and compromises
 Complex asynchronous behavior blocks understanding
 Escalating threats and consequences
 Approach
 Mathematical semantics first, engineering practices later
 Develop engineering foundations that address system realities
 Limit complexity and improve survivability with practical engineering
methods

Three Key Questions
 In a world of large-scale, asynchronous
network systems with dynamic function and
structure …
1. What are the unifying engineering foundations
for system analysis, specification, and design?
2. How should quality attributes such as
survivability, reliability, and performance be
specified and achieved?
3. What architecture frameworks can simplify
system development and operation?

Foundations: First-Class Artifacts
 Flow
 Defines mission, user functions and quality
attributes, refines into service uses
 Service
 Provides functionality and quality attributes, refines
into flows
 Quality
 Attribute requirements attached to flows, service
attribute matches computed dynamically

Three Engineering Concepts
 In a world of large-scale, asynchronous, network-centric
systems with dynamic functionality and structure …
1. Flow Structures
User task flows and their architecture flows of service uses are
engineering anchors for analysis, specification, and design of
functionality and quality attributes.
2. Computational Quality Attributes
Quality attributes can be specified as dynamic functional
properties to be computed, not as static, a priori predictions.
3. Dynamic Flow Management
User task flow designs support architecture templates that
manage flows and their quality attributes in execution.

Flow Structure Concepts Flows traverse a network
architecture to satisfy
mission requirements
Enterprise Users Systems

Architecture flow
User task flow of service uses
User task flow Architecture flow

Enterprise mission of service uses
Enterprise mission is embodied in user User task flow Architecture flow

of service uses
task flows of operations and decisions in
system usage Architecture flow refinements of user task flows define uses of
system services that provide function and quality attributes
Gas purchase flow:
customer
credit
database
land land
gas telecom satellite telecom credit card
pump telecom company
system 1 system 2 system 3 system 4 system 5

Analysis: From Systems to Flows
Pervasive Existing Response-based semantics for shared
asynchronous network services gives flows deterministic
behavior properties for understanding and
architecture abstraction
mission flow 1
task 1 flow 3
mission
task 3
mission flow 2
task 2
Flows reveal survivability

dependencies for resistance,
recognition, and recovery
analysis and improvement

Design: From Flows to Systems
 User task flow design

 Flow Structures of mission tasks can be designed and
verified at multiple levels of refinement
 Network behavior specification
 A network system specification is the set of flows of its
service uses
 Component service specification
 The specification of each service in a network system
incorporates all its uses in all flows where it appears

Management: Flows from Start to
End
 Manage Flow Structures as first-class artifacts in
 Acquisition
 Development
 Testing
 Operation
 Evolution
 System implementation and operation must
satisfy Flow Structure function and quality
attributes

FSQ Foundations
 Flows of user tasks and their refinements into architecture
service uses are fundamental engineering bedrock for
network-centric systems.
 Mathematical semantics of flows makes them deterministic
to limit complexity for human understanding despite
asynchronous behavior of their service uses.
 Flow Structures require survivability design for Uncertainty
Factors of failure, disruption, and compromise.
 Flow Structures can be refined, abstracted, and verified with
precision despite uncertainty of COTS behavior.
 Flow Structures specify integration and interoperability of
stovepipes and systems-of-systems, and define quality
attributes such as reliability and survivability.
 Flow Structures can be extracted from existing systems to
reveal security and survivability problems.
Flow Design of Network-Centric War Fighter
FlowSets for the Future Combat System:
Other Layered FlowSet:
FlowSet: Sensors FlowSet: Preparation
Preparation Preparation Deployment
Launch Launch C3
C3 C3 Retrieval
Retrieval Maintenance Safing
Maintenance .. Maintenance
…
…
UAVs
FlowSet:
Network Mission Def’n Robotic
Sensor Integration Sensors
Centric C4I
FlowSet: Force Fire Integration FlowSet:
Preparation Damage Assmt Preparation
Deployment … Deployment
C3 C3
Retrieval Retrieval
Safing Safing
Maintenance Maintenance
… …
Robotic Robotic
Direct Fire FlowSet: NLOS Fire
• Distributed platforms Preparation Flow Structures define services and
Deployment networks, link stovepipes, manage
• System-of-systems C3
• 100s of nodes and users Maintenance
quality attributes, support both
• Nodes and usage change/evolve Manned C2 … centralized and distributed control
FSQ Research Directions
 Complete Theory Development
 Flow Structure Semantics
 Computational Quality Attributes
 Flow Management Architectures
 Exploratory Case Studies
 Engineering Practices
 Industrial Collaborators/Customers
 Automation Opportunities

Parallelism and Coordination
 Parallel applications are composed of interacting
processes focused on specific tasks, but working
toward a common goal. Coordination languages
allow individual processes to wait for needed data,
pursue local computations, and communicate any
results to other processes
 Cloud computing makes parallel programming

relevant again and more accessible for a wide variety
of applications!

Parallelism: JavaSpaces
Supports uncoupled
programming.
Indirect communication
enables space and time
decoupling.
 space.write(entry, null, Lease.FOREVER);
 space.read(template, null, Long.MAX_VALUE);
 space.take(template, null, JavaSpaces.NO_WAIT);
Freeman et al., 1999

Parallelism: MAPREDUCE
MAPREDUCE is a straightforward
approach to parallelism consisting
of a map phase that splits up and
distributes data for computations,
applies any user-defined
procedures, and employs a reduce
phase that collects the results.
How do we design, develop, visualize,

and debug such complex programs?
http://institute.lanl.gov/isti/irhpit/projects/ Dean and Ghemawat, 2004

Analytics on the Cloud
 Analytics has always had two components
 An off-line component that crunches numbers to build predictive
models, and
 an on-line component that uses models that have been built
 Both components now have support from vendors (e.g.

Mathematica, Zementis)
 Merv Adrian, a reporter for CIO.com notes, “By shifting their data
warehouse into an agile, virtualized infrastructure, T-Mobile now
has flexible access to more data and can analyze and rethink at
will. Like Fox, they're able to build analytical "sandboxes" on-
demand to discover new questions. Grab data to explore those
questions. Tear it down, and do it again.”

Analytics on the Cloud: Research
Opportunities in Security
 The challenge here is to strategically distribute data in this
manner to minimize the data loss risk
 Both horizontal (entire records being assigned to different

servers) or vertical (columns in data being assigned) distribution
strategies, or hybrids, may be of interest to study
 Encryption, distributed data mining are two areas that can inform
some of this work
 Also, in areas such as heath care with specific policies and

consumer laws, the design of compliant algorithms will be an
important area

Analytics on the Cloud: Some
Algorithmic Opportunities
 A promising area of research is the study and design of methods for scaling
machine learning algorithms on the cloud. In general, “exporting” most existing
algorithms to the cloud will involve newer techniques to take advantage of the
scaling that may be available.
 If cost is not a consideration (i.e. scaling to large number of CPUs does not cost
any more) then clearly approaches such as MapReduce can be used to break
large problems into as many smaller pieces as possible. However cost sensitive
approaches will need to determine, based on needs, what level of parallelization
may be worth the execution cost on the cloud.
 On the supply side, how should these services be priced given such
considerations?
 Implementing dynamic scaling at runtime. How should resources and distribution

be managed at run-time to adhere to performance constraints?

The Future of Cloud Computing
 Providers will successfully navigate the obstacles
and turn them into opportunities
 Next generation systems will be designed and
deployed via the Cloud
 Applications software will have both a piece on the client
and a piece in the Cloud, decoupled as needed
 Infrastructure software will be commoditized and run on
virtual machines
 Hardware will be boxed differently
 The Economics of Computing and Pricing (SW and
HW) will change
 IT Spending on Cloud Ratcheting Up

Staffing for Cloud Development

Conclusion
 Cloud computing is radically transforming the IT industry
 Apple’s iCloud
 Amazon Web Services
 Microsoft Azure
 IBM Cloud
 The demand for rigorous research to study the
opportunities and challenges on the cloud will be met by
those research communities best positioned to move
aggressively with industry-relevant projects.
 Call for the IT community to lead research on the
successful analysis, design, deployment, and use of cloud
computing strategies and applications

Internet of Things Software
Development
 Many future software systems will contain
IoT components and capabilities
 SCADA Systems – Manufacturing
Controls
 Smart Cities Systems
 Water Control Systems - SWIFTMUD

Internet of Things (IoT) Realities
 Internet of Things (IoT) systems exhibit
unprecedented levels of scale and complexity
 User transaction flows traverse systems and
components of varying quality and reliability
 Complications arise from the variety of
architectures, platforms, languages, protocols,
organizations, and users that will be involved
 Yet IoT systems must provide unprecedented levels
of reliability and dependability for effective Smart
City operations
Copyright 2018 Alan

36 October 25, 2018 Hevner
IoT Uncertainties
 The Uncertainty Factors
 Components and connections come and go
 Capabilities correct or incorrect, available,
unavailable, compromised
 Attacks and intrusions persistent and unpredictable
 Users and needs constantly changing
 How can a rigorous engineering discipline be

defined for this environment?
 Without it, we believe intellectual control is impossible
Copyright 2018 Alan

IoT Reference Architectures
 An IoT reference architecture provides a common
understanding and vocabulary for interoperability and
communication across various platforms in an IoT
system
 Given a standard reference architecture, businesses
and developers can create compliant IoT solutions for
specific application ecosystems, such as Smart Cities
 The complexities and compromises in developing an
acceptable IoT reference architecture are enormous,
and we are just beginning to see initial proposals from
standards organizations (e.g. EU ARM 2013) and
industry (e.g. Cisco 2014).
Copyright 2018 Alan

IoT Architecture Structures
 Current IoT reference architectures predominately
address the elements and structures of IoT systems:
 Components – Sensors, Computers, Data Repositories,
Servers, Platforms, etc.
 Connectors – Networks, Pipes, Telecommunications, etc.
 Configurations – Patterns for components and connectors
in well-defined arrangements.
 Protocols – Detailed support for data flows and control
flows within and between configurations.
 Missing are the Computational and Behavioral
Semantics of IoT system applications
Copyright 2018 Alan

Computational Semantics
 Computational Semantics of IoT reference architecture
 Grounded on past research on the FSQ (Flow-Service-
Quality) model of software systems engineering (IBM,
SEI/CERT)
 Flows – Rules that support application flow creation,
initiation, synchronization completion, deletion, etc.
 Qualities – Measures of correctness, efficiency,
security, and other important attributes
 Evolution – Growing the reference architecture based
on changes in goals, environments, and technologies
Copyright 2018 Alan

Flow Semantics
 IoT transactions are composed of flows of control and data
through IoT architectural structures (i.e. components,
connectors, and configurations)
 Methods for creation, instantiation, execution, monitoring,
completion, and deletion of IoT transactions are required for
any application domain
 User task flows and their refinements into invocations of other
flows and system services can provide a unified engineering
foundation for analysis, specification, design, and verification
of required functionality and quality attributes
 Engineering development of task flows can be augmented by
computational automation for behavioral analysis of flows and
their components
Copyright 2018 Alan

Quality Semantics
 Quality attributes can be associated with flows and the system
services they invoke, and are specified as dynamic mathematical
properties to be computed, rather than as a priori predictions of
limited value in real-time operations
 Three semantic quality objectives can be identified:
 A flow transaction will require minimum levels of quality to be successfully
performed. How do we define the quality requirements of a designed user
transaction on an IoT architecture?
 As a transaction is instantiated on a particular IoT system at a given point
in time, how can we predict the quality levels that are available? This will
depend on the current state of the IoT system in terms of capacity, load,
reliability, and many other system state variables. If the required levels of
quality cannot be currently provided, a decision must be made whether to
perform the transaction or wait until a sufficient level of quality can be
obtained in the system.
 What management mechanisms are needed in an IoT system to monitor
the progress of an executing transaction to ensure that the quality levels
are achieved? If certain qualities are falling short, dynamic flow
management may be required to alter the flow path or abort the
transaction and reinitiate it at a later time.
Copyright 2018 Alan
Evolution Semantics
 Flow Semantics and Quality Semantics prescribe
requirements for IoT architecture semantics focused on
management and governance of user functionality and data in
a bounded application domain
 In complex IoT environments, however, it is not possible to
completely predict all possible system behaviors. New and
unpredictable behaviors will emerge over time and must be
recognized and managed
 An IoT architecture must evolve and adapt over time based
on changes in goals, ecosystems, and technologies.
Evolution Semantics will prescribe processes for managing
and directing this evolution while maintaining current
operational capabilities.
 Goals are IoT robustness, sustainability, and ethical uses
Copyright 2018 Alan

Flow Semantics: An Engineering
Discipline for IoT Software
 What is a Flow?
 Traversal of IoT components to perform a task for a user or a
flow
 Combines capabilities of components that may be asynchronous
 Flows invoke other flows; flow hierarchies and flowsets
 First-class engineering concept for IoT systems
 Overarching requirements for flow engineering foundations

 Must be deterministic for design & verification despite
asynchronism
 Must be suitably responsive despite Uncertainty Factors
Copyright 2018 Alan

Foundations of Flow Semantics
 Flow specification
 Defines only processing internal to a flow, not the
unpredictable processing of the flows it invokes
 Defines actions by a flow for all possible responses from
invoked flows, both desired and undesired
 Implications
 Reasoning about flow design and verification is localized,
yet complete
 Flows can be defined by deterministic structures despite
asynchronism
 Flows can be designed to be responsive to Uncertainty
Factors
Copyright 2018 Alan
 Semantics of flow components for determinism and responsiveness
 Extend traditional functional programming semantics to Response-Based Semantics
(RBS):
Stimulus (S) Response

… IoT Flow Component (R) …
Invocation Invocation
Stimulus Response
History (ISH) History (IRH)
External Flow
 Transition function (domain to range) f: ( S x IRH  R x ISH)
Copyright 2018 Alan

 Invocation Response History (IRH)
 Embodies Uncertainty Factor response outputs
 Part of domain because invoking component can depend on it
 Invocation Stimulus History (ISH)
 Input to generate Uncertainty Factor responses from invoked
flow
 Part of range because subsequent flow invocations will use it
 Resulting component properties
 Deterministic design, verification does not depend on lower level
flows
 Self-contained yet responsive to Uncertainty Factors
Copyright 2018 Alan

Flows Superimposed on an IoT Architecture
• Flow refinement, abstraction and verification
IoT Network Architecture
mission flow 1
task 1
flow 3 mission
task 3
mission flow 2
task 2
Flow refinement, Pervasive Response-Based Semantics for flow components

abstraction, and asynchronous allows deterministic development and Uncertainty
behavior Factor responsiveness
verification

Smart City IoT Systems
 Extraordinary complexity in development,
operation, and evolution
 Intellectual control critical to success
 Engineering foundations key to intellectual
control
 Reference architectures essential but
insufficient
 Semantic foundations required as well
Copyright 2018 Alan

Conceptual Flowsets for a Smart City IoT
Flowsets: Flowsets: Flowsets: Reachback/
Capacity Monitoring Data Aggregation & Analysis Demand Monitoring Supply Chain
Demand Monitoring Generation Control Power Generation Flowsets
Environmental Transmission Control Environmental Monitoring
Monitoring Distribution Control Maintenance and Upgrade Weather
Financial Operations Consumption Control Financial Operations Monitoring
Energy Management & Service Generation

Markets Governance Providers
Additional Reachback/Supply Chain

Feedstock
Equipment
Suppliers
Flowsets
ion …
Bulk/Renewable Power Local Power Maintenance
Generation Transmission Distribution Consumers Crews/Materials
Flowsets: Flowsets: Flowsets: Flowsets:

Transportation
Coal/Oil Operations High-Voltage Low Voltage Operations Industrial Customers
Facilities
Natural Gas Operations Operations Substation Operations Business Customers
Renewable Operations Substation Operations Local Distribution Residential Customers
Financial
Markets
Sensing and Actuating
Education and
Flowsets:
Training
Reading and Transmitting Data
Actuating Devices …
Copyright 2018 Alan

Flow Semantics - The Big Picture
 Research in Flow Semantics is complementary to IoT architecture
research, which currently focuses primarily on structural properties.
While structural aspects are important for IoT development, the
semantics of IoT operations, which are software-defined at virtually
every level, are essential to developing and governing these
systems.
 Flows invoke other flows across large-scale networks at all levels,
even with reachback to supply chains in virtually endless
interactions
 Complexities can seem daunting, but deterministic flows
implementing Response-Based Semantics and design for
Uncertainty Factors localize human understanding while providing
required functionality
 This is the whole point:
Creating and operating IoT systems under intellectual control
Copyright 2018 Alan

Observations
 Flows help organize and aggregate IoT governance around mission
objectives at all levels, from systems down to sensors and
controllers
 Flows can be defined to be deterministic for localized reasoning and
verification while nevertheless embodying dependencies on other
flows in a system
 Flows can provide deterministic operations despite the underlying
asynchronism of IoT systems
 Flows can be designed to deal with Uncertainty Factors through
implementation of Response-Based Semantics for operational
resiliency and survivability
 Flows are scale-free, with the same principles and processes
involved in high-level and low-level flow development and operation
 Flows are implementation-independent, and can serve as first-class
concepts for IoT system specification and development
Copyright 2018 Alan

Future Research Directions
 Future research on Flow Semantics will include
instrumented case studies dealing with real-world
problems in IoT system development
 Research in Flow Semantics automation will help drive
adoption of this technology. Of particular importance in
this regard is extension of the science and technology
of automated software behavior computation for
development and verification of flowsets across IoT
architectures and languages
 Further, we will extend the reach of IoT semantics to
Quality Semantics and Evolution Semantics and apply
these new ideas to Smart City IoT applications
Copyright 2018 Alan

Platform-based Software
Development
 Doctoral Dissertation by Onkar Malgonde
 June 2018
 The digital platform is a pervasive digital
technology that is rapidly transforming the
ways in which products and services are
produced and consumed in our market
economy
 Parker, G.G., Van Alstyne, M.W., and Choudary,
S.P., 2016
54 Copyright
October
2018
25,
Alan
2018
Hevner
Digital Platforms
Digital Platform Ecosystem
October 25, 2018 55 Copyright 2018 Alan Hevner

Challenges for application producers in
a platform ecosystem
 As platform’s core value evolves, platform applications are added, updated,
and dropped
 Similarity of applications incentivizes the platform to assimilate those

features into the core value proposition of the platform
 All applications must adhere to connection specifications and development

procedures determined by the platform
 Platform owners evaluate and approve new applications (curation

mechanisms)
 Changes to platform architecture and governance mechanisms requires

application producers to adapt their applications and routines to comply with
updated platform regulations

Challenges for application producers in
a platform ecosystem
 Application-platform match
 Application-market match
 Value propositions exceeding platform’s core

value propositions
 Novelty

Research Questions
 What software development methods best
support software development teams to
design, build, evaluate, and deploy novel
applications on digital platforms?
 How do software development teams

incorporate effectual thinking in the
development of novel applications on digital
platform?

An Effectual approach to software
development
 To manage key challenges and achieve desired properties:
 Propose and validate an effectual approach to application
development that is grounded in the theory of effectuation
 Project manager and development team are envisioned as

entrepreneurs
 Adapt entrepreneurial risk in application development on

software platforms
 The proposed effectual approach to software development

consists of two phases: (a) planning, and (b) execution and
monitoring

IS and Entrepreneurship
 Entrepreneurship literature informs the effectual software
development process
 Provides key constructs and decision heuristics for the design

of the artifact
 Provides lens to identify and explain new aspects of software

development
 Theorizing above and beyond the enabler role played by

information technology in entrepreneurial ventures
Copyright 2018 Alan Hevner

60 October 25, 2018
Theory of Effectuation
(Sarasvathy 2001)

Prediction vs Control in Software
Development
Framework of Prediction and Control (adapted from Wiltbank, R., Dew, N., Read, S., and Sarasvathy, S. 2006)

Preliminary Research Model

Preliminary Study 1
 As an initial investigation of the effectual research model, we study
an existing open source environment that supports the development
of applications on digital platforms
 We identified Apache Cordova as an open-source mobile

application development framework
 We focus on user stories that describe a specific feature request

and/or issue with the application and/or platform
 Story descriptions and related comments for 1,051 stories are

extracted. Our data analysis is supported with documents from
proposals, board reports, and project documentation.

Apache Cordova Architecture
From
https://cordova.apache.org/docs/en/latest/guide/overview/index.html

Research Method
 Initial inspection retained 42 user stories with sufficient detail
for data analysis
 Atlas.ti qualitative data analysis software
 Develop a qualitative codebook that identifies subcodes and

operational definitions for each construct in our model
 Using descriptive coding technique, subcodes from the

codebook are applied to each story

Results
Construct First Cycle Code Frequency
Technology 40
Market knowledge 5
Means
Platform knowledge 20
Constructs Social Capital 2
and their Technology 23
Frequency Platform Market 7
in the Data Value 8
Product-market match 8
Product-platform match 24
Aspirations
Exceed Platform Value 14
Novelty 15
Commit limited resource 33
Acceptable Risk Application recoverable after failure 5
Risk Analysis 21
Logic of Control Logic of Control 32
Fixed bugs 20
Action
Completed Tasks 11
New technological knowledge 37
Expanding Cycle of Resources New market knowledge 5
New platform knowledge 21
Converging technological constraints 24
Converging Cycle of Constraints Converging feature constraints 9
Converging platform constraints 11

Preliminary Study 2
 2 Pilot Interviews
 IT-department of a non-profit educational organization
 Fortune-500 organization
 Validate and augment the research model
 Develop the interview protocol for a broader qualitative study.

 interview protocol is based on the operational definitions
developed in the preliminary study
 Open coding of interview transcripts

Revised Model

Research Design
• Unit of Analysis
• Software
Development Project
• Theoretical Sampling
• Digital platform
• Novelty of
application
• Competing
applications
• 2 local organizations

Data Analysis
 Data
 16 interviews (AT – 9; TB- 7)
 630 minutes
 869 passages coded
 Open Coding
 2 graduate students trained with pilot interviews
 Cohen’s Kappa greater than 70% for each interview
 Axial Coding

AT Case Study

AT Case Study
No Interviewee’s Title Key Points
AT - Delivery Client relationship, requirements, budget, timeline, align business and development; rapid prototyping to understand business;
1 Leader workshops to identify requirements; discuss backlog items before sprint planning; time and budget influence logic of control;
iterative process
AT – Senior Web API development and maintenance; back-end developer; key aspirations – product platform match and exceed platform’s
2 Developer value; Microsoft Azure used to setup development and test environment which takes away complexity of maintaining these
environments; Microsoft core provider; platforms do not provide all functionality;
AT – Senior Focused on video playback feature; given the time and resources, change aspirations of video player behavior; time sensitive
3 Developer launch for conference; accepted bugs to meet timeline; discuss questions about features with clients; product platform match is
a moving target
AT – UI Developer Development of UI with Xamarian wrapper for iOS; limitations of Xamarian to support video playback; tweak platform
4 components for desired results; AT is recommending rather than decision-making;
AT – Senior Design, development, and release to Apple’s AppStore; 2 releases, waiting for 3rd release; trial and error; backlog grooming;
5 Developer client decision
AT – Delivery Technology-driven recommendations to improve the product; consulting versus contracting; in both situations, AT is order-
6 Leader (Final Stage) taking mode
AT – Delivery Rapid prototyping; feedback from client; get the application to match platform and market, then focus on novelty if budget and
7 Leader (Phase One) time permits; compromise with client on issues that cannot be completely fixed; focus on scope, budget, and timeline;
AT – Technical Set technical direction; build backlog with ideas and groom backlog to prioritize; clients come up with ideas; technical team
8 Architect brings ideas; ultimate decision by client; subtle enhancements to feature; chaining experiences; new ideas from experience,
platform, and technical expertise; testing identifies improvements and ideas for next sprints; application’s usage data identifies
focus areas
AT – UI Designer User interface design for mock ups – 32 screens, Sketch – Mac application to develop; collaborate to identify features; 80-85%
9 features identified prior to development;

TB Case Study

TB Case Study
No Interviewee’s Title Key Points
1 TB – Product Owner Backlog items from customers, prospective customers, knowledge about the market; prioritize backlog
items; 4-week sprints; types of users for modules; Microsoft integration; intellectual property;
functional team identifies ideas, discuss with technical architects which provide feedback; remove
features that drain performance;
2 TB – Practice Manager Implementation; training; Microsoft platform enables scalable and robustness; product platform match
is a given as product is built on the platform; 80-90% of functionality is provided by the core product,
rest is custom built; Microsoft provide APIs, tools, connectors, and adapters to migrate data
3 TB – Product Manager Customers familiar with Microsoft suite; springboard customers; easily find information; data model;
ease of use, patient-centric, and open standard interface; all 5 modules on one platform; multiple data
points for feature requests; platform release cycle; build on platform release; prototype to debate
features;
4 TB – Solutions Consultant Registered nurse; pre-sales; nurses, customer service agents, program managers, directors, system
administrators; platform is weaved into conversations; license to use application from Microsoft; low
visibility in the context
5 TB – Technical Architect Offshore development team; in-house development; advanced APIs such as speech recognition;
outsource UI design; platform limitations with other platforms at customer side; trial and error –
difficult to track; proof of concepts areas in sandbox;
6 TB – Solution Architect Small module size; bringing together CRM and healthcare; roadmap; realistic in two weeks’ time;
platform enables new tools which are production ready; frequent updates to platform requires
refactoring; “we will figure out the platform later”;
7 TB – Functional Consultant Agile; partnerships; prioritize items; visual representation; technical input to develop idea;

Study Validity
 Construct Validity
 Triangulation
 Chain of evidence
 Internal Validity
 open interview questions
 follow up questions to identify confounding explanations
 multiple informants.
 External Validity
 Multiple studies
 Reliability
 Operational definitions
 Triangulation of Validation

Research Implications
 Novelty of the Application
 Traditional focus – budget, timeliness, and quality
 features and extensions which are not provided by the digital

platform and competing applications
 effectual cycle emphasizes the team’s resources to identify,

incorporate, and expand novel features in the application
 serendipitous identification and evaluation of ideas
 feedback loop between aspirations of the team and design

artifacts

 Effectuation Design Cycle
 Fast and tight design cycles
 broader design artifacts to include proof of

concepts, working code, prototypes, design
interfaces, among others
 each iteration focuses on evaluating a specific

aspect of team’s aspirations

 Balancing Prediction and Control
 allteam members follow the approach identified
by the project manager
 we find that team members incorporate adhere to

different approaches
 based on the application’s current state of

development, team members alter their
adherence to different approaches

TB Case
AT Case
October 25, 2018 80 Copyright 2018 Alan Hevner

 Artifacts to support Planning and
Execution and Monitoring

 Artifact to support Planning

 Artifact to support Execution and Monitoring

Theoretical Contributions
 develop a research model of effectual software
development process by extending the theory of
effectuation
 contributes to the theory of software development by

borrowing effectuation perspective from the
entrepreneurship domain and strategic management
 illustrates the approach adopted by different team

members, even though the overall approach by the
team is effectual

IS Contributions
 Focus on digital platforms for software
development
 identify new challenges faced by application

development teams in platform environment—
product-platform match, exceed platform’s core
value proposition, and novelty
 illustrating the theoretical underpinnings of

software development approaches

Limitations
 an inherent limitation of case study research is the
generalizability of its findings beyond the context
 our case studies included teams of medium size. Applicability

of the inferences drawn from this research to large software
development teams may need additional analysis
 the cases considered in this research represent in-house

development and client-vendor relationship. For software
application projects where the development is offshored may
require additional analysis

Future Research
 Design Science research to develop process models
for planning and execution and monitoring phases
 Control theory perspective

 Portfolio of controls
 configuration, dynamics, and enactment, of control modes
 Other application context such as cloud and

blockchain

Conclusion
 Digital Platforms identify new challenges for software
application development teams
 Software development teams need entrepreneurial thinking
 Effectual approach to software development extends our

thinking to develop novel applications in the context of digital
platforms
 Different roles in the team follow different approaches

Class 10 Discussion Question
 Discuss your experience with software
development in either a cloud computing
environment or an Internet of Thing (IoT)
computing environment. How does this new
environment change the ways you and your
organization develop software systems?

Quiz 2 Review
 Given on November 1
 Closed Book, Closed Notes
 90 minutes in Class
 5 short answer questions
 Classes 6 – 10 material covered

Class 6 Outline
 Introduction to ICASE
 ICASE tools
 UML tools
 Introduction to ArgoUML
 UML Diagrams
 Tutorial

Class 7 Outline
 Reengineering of Systems
 Business Reengineering
 A Taxonomy of Reengineering
 Metrics
 Project and Software Measurements
 Types of Metrics
 Inspections
 Types of Analyses
 Automated Tools for Software Development
 Computer-Aided Software Engineering (CASE) Environments
 CASE Architectures
 Management Implications of Tools
 GreenIT
 IT Impacts on Sustainability
 Research and Development Directions
 Human-Computer Interfaces & Interactions (HCI)
 What is HCI?
 What is Usability?
 User-Centered Systems Development
 Designing Interactions
 Best Practices
 Material from the SPMN website will be discussed.
Class 8 Outline
 Software Security Basics
 SecurityPractices in the Software
Development Life Cycle
 Cybersecurity Threats
 Software Testing for Security
 Social Engineering
 Application Security
 ReliaQuest Guest Speakers

Class 9 Outline
 Larry Gioia’s Presentation
 Covey’s Management Ideas
 Maslow’s Hierarchy of Needs
 Pink’s Video of Motivation
 Blanchard’s One-Minute Manager
 Deming’s Statistical Quality Control
 Peopleware – DeMarco and Lister
 Larry’s Best and Worst Practices

Class 10 Outline
 The Cloud
 Cloud Computing
 Industry Clouds
 Research Directions in the Cloud
 The Future of the Cloud
 Flow-Service-Quality Methods of Specification and Design
 Internet of Things Software Development
 Intellectual Control of IoT Systems
 Semantics (Flow, Quality, Evolution)
 Smart City Examples
 Platform-based Software Development
 Effectual Software Development on Platforms
 Research Contributions and Future Directions

Advanced Information Systems Analysis and Design: Class 10: New Directions in Software Development

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced Information Systems Analysis and Design: Class 10: New Directions in Software Development

Uploaded by

Copyright:

Available Formats

Advanced Information Systems

Analysis and Design

October 25, 2018 Copyright 2018 Alan Hevner 1

October 25, 2018 Copyright 2018 Alan Hevner 3

 A lot of the industry standard business functions can

 Head of Syntel's Cloud Computing Center of Excellence

4 October 25, 2018 Copyright 2018 Alan Hevner

5 October 25, 2018 Copyright 2018 Alan Hevner

6 October 25, 2018 Copyright 2018 Alan Hevner

7 October 25, 2018 Copyright 2018 Alan Hevner

 To effectively capture this organizational decision-making, we propose a six-

 The dimensions are:

8 October 25, 2018 Copyright 2018 Alan Hevner

October 25, 2018 Copyright 2018 Alan Hevner 9

 An organization might for instance choose to have high

 Thus, each dimension has a separate ‘control knob’ to

10 October 25, 2018 Copyright 2018 Alan Hevner

October 25, 2018 Copyright 2018 Alan Hevner 11

Copyright 2018 Alan Hevner October 25, 2018 12

Copyright 2018 Alan Hevner October 25, 2018

 Parallel Processing and Coordination

 Analytics on the Cloud

14 October 25, 2018 Copyright 2018 Alan Hevner

October 25, 2018 Copyright 2018 Alan Hevner 15

October 25, 2018 Copyright 2018 Alan Hevner 16

October 25, 2018 Copyright 2018 Alan Hevner 17

October 25, 2018 Copyright 2018 Alan Hevner 18

Enterprise Users Systems

User task flow Architecture flow

Enterprise mission is embodied in user User task flow Architecture flow

Gas purchase flow:

system 1 system 2 system 3 system 4 system 5

October 25, 2018 Copyright 2018 Alan Hevner 19

Flows reveal survivability

October 25, 2018 Copyright 2018 Alan Hevner 20

 User task flow design

October 25, 2018 Copyright 2018 Alan Hevner 21

October 25, 2018 Copyright 2018 Alan Hevner 22

October 25, 2018 Copyright 2018 Alan Hevner 25

 Cloud computing makes parallel programming

26 October 25, 2018 Copyright 2018 Alan Hevner

October 25, 2018 Copyright 2018 Alan Hevner 27

How do we design, develop, visualize,

http://institute.lanl.gov/isti/irhpit/projects/ Dean and Ghemawat, 2004

 Both components now have support from vendors (e.g.

29 October 25, 2018 Copyright 2018 Alan Hevner

 Both horizontal (entire records being assigned to different

 Also, in areas such as heath care with specific policies and

30 October 25, 2018 Copyright 2018 Alan Hevner

 Implementing dynamic scaling at runtime. How should resources and distribution

31 October 25, 2018 Copyright 2018 Alan Hevner

32 October 25, 2018 Copyright 2018 Alan Hevner

October 25, 2018 Copyright 2018 Alan Hevner 33

34 October 25, 2018 Copyright 2018 Alan Hevner

October 25, 2018 Copyright 2018 Alan Hevner 35

Copyright 2018 Alan

 How can a rigorous engineering discipline be

Copyright 2018 Alan

Copyright 2018 Alan

Copyright 2018 Alan

Copyright 2018 Alan

Copyright 2018 Alan

Copyright 2018 Alan