Systems Integration

Course Description

Systems Integration examines the process of integration of different software systems and applications into an organization. The curriculum addresses key challenges in combining software systems within large organisational contexts, including establishing requirements, implementing security measures, ensuring interoperability, documenting business processes, providing support, conducting testing, and performing maintenance.

Within the SCNS taxonomy, CEN is the Computer Systems and Software Engineering prefix. Daytona State publishes this at 3 credits, offered fall, with COP4708 and COP3530 as prerequisites. ⚠ The single term of offering is worth planning around, particularly since COP4708 must precede it.

Integration is where most real enterprise computing actually happens, and it is badly under-taught relative to how much of the work it is. Organisations rarely build one system; they accumulate a dozen over twenty years, bought from different vendors, built on different assumptions, holding overlapping and inconsistent versions of the same data. The job is making them work together without a rewrite — and the hard parts are not technical protocols but reconciling systems that disagree about what a customer is.

Daytona State does not publish a lecture and laboratory split for this course. Its computing and office systems courses are unsuffixed and run at the standard 15 contact hours per credit — CEN4010, CEN3722, CNT2402, OST2401 and CGS1570 are all live at 3 credits and 45 hours. This course is priced at that convention.

Learning Outcomes

Required Outcomes

• Describe systems integration and why organisations need it.
• Describe integration patterns and architectural styles.
• Describe point-to-point, hub-and-spoke, and bus architectures.
• Describe application programming interfaces and their design.
• Describe messaging, queuing, and event-driven integration.
• Describe synchronous and asynchronous integration and their trade-offs.
• Describe data formats and transformation between them.
• Establish integration requirements from business processes.
• Document business processes and map them across systems.
• Reconcile differing data models between systems.
• Describe master data management and the single-source-of-truth problem.
• Plan and execute data migration.
• Validate migrated data and reconcile discrepancies.
• Describe interoperability standards and their role.
• Design and implement security controls across a trust boundary.
• Describe authentication and authorisation between systems.
• Manage credentials and service accounts securely.
• Describe error handling, retry, and idempotency in integrations.
• Design logging and monitoring for an integration.
• Plan and conduct integration testing.
• Describe the limits of testing against non-production systems.
• Plan cutover, rollback, and support.
• Describe maintenance and versioning of integrations.
• Document an integration so that someone else can support it.

Optional Outcomes

• Describe enterprise service buses and middleware platforms.
• Describe microservices and service decomposition.
• Describe cloud and hybrid integration.
• Describe legacy system modernisation strategies.
• Describe vendor selection and contract considerations.
• Describe integration in a regulated environment.

Major Topics

Required Topics

• Systems integration and its drivers
• Integration patterns and styles
• Point-to-point, hub-and-spoke, bus
• APIs and their design
• Messaging and event-driven integration
• Synchronous versus asynchronous
• Data formats and transformation
• Integration requirements
• Business process documentation and mapping
• Reconciling data models
• Master data management
• Data migration
• Migration validation
• Interoperability standards
• Security across trust boundaries
• Authentication and authorisation between systems
• Credential and service account management
• Error handling, retry, and idempotency
• Logging and monitoring
• Integration testing
• Limits of non-production testing
• Cutover, rollback, and support
• Maintenance and versioning
• Documentation for supportability

Optional Topics

• Enterprise service buses
• Microservices
• Cloud and hybrid integration
• Legacy modernisation
• Vendor selection
• Integration under regulation

Resources & Tools

• Build things and keep them. In computing the portfolio is the qualification — a public repository of working projects with readable code and a clear README does more for employment than a transcript.
• Git and a public repository host — free; version control is expected of every candidate, and using it from your first course is the cheapest habit to acquire.
• Free-tier cloud accounts (AWS, Azure, Google Cloud, Oracle) — real infrastructure to practise on at no cost; set a billing alert before you start.
• Virtualisation and containers — VirtualBox and Docker are free, and a broken lab you can rebuild in a minute is what makes experimentation cheap.
• Official documentation — language, database, and framework docs are authoritative and version-correct in a way that copied answers are not. Learning to read documentation is the skill that separates practitioners.
• Vendor certifications — Microsoft, AWS, Oracle, CompTIA and Cisco credentials are named by employers in job advertisements; many have free training paths and student pricing.
• Your instructors and the lab — supervised time on real systems is the part you cannot get from a video.
• Internships and co-op placements — the strongest single predictor of employment at graduation. Start looking a year before you think you should.

Career Pathways

• Software developer — SOC 15-1252.
• Computer systems analyst — SOC 15-1211; the requirements-and-design role.
• Database administrator and architect — SOC 15-1242 and 15-1243.
• Data analyst, business intelligence developer, and data engineer — strong demand and a common entry route for people who like data more than application code.
• Network architect — SOC 15-1241; and network and systems administrator, SOC 15-1244.
• Information security analyst — SOC 15-1212; strong growth, and systems or database work is the usual route in.
• Data scientist and machine learning practitioner — SOC 15-2051.
• Systems integration and enterprise applications — frequently overlooked by students and consistently well paid.
• Florida's defence, space, and simulation sector, plus healthcare, hospitality, financial services and a large public sector — ⚠ many defence roles require U.S. citizenship and some a security clearance.
• Managed service providers and consultancies — broad exposure quickly, and a common early career step.
• Continue to a bachelor's or graduate degree — Daytona State's computing bachelor's programmes are the direct route.

Special Information

⚠⚠ Integrations are where the security holes live

• An integration is a trust boundary, and it is frequently the least examined one in an organisation. The systems on each side were secured; the pipe between them was built to make something work by a deadline.
• ⚠⚠ Service accounts accumulate excessive privilege. The commonest pattern is an account granted broad rights because narrowing them was fiddly, then never revisited — and that account becomes the most valuable credential in the organisation. Apply least privilege and review it.
• ⚠ Never hard-code credentials, and never commit them. Secrets in a source repository are found by automated scanners within minutes of being pushed, and repository history keeps them after you delete the line.
• Authenticate and authorise both ends, and do not assume a call is legitimate because it came from inside the network.
• Validate everything crossing the boundary. A system that trusts its input because "the other system already validated it" is how injection reaches a database that was otherwise well protected.
• Encrypt in transit, always, including inside a private network.
• ⚠ Log what crossed and when, and monitor for the unusual — volume spikes, off-hours activity, and repeated failures. An integration nobody watches is an integration nobody notices being abused.
• Handle errors deliberately. Retries without idempotency duplicate transactions, and a failure that silently drops a message is worse than one that stops loudly.
• Do not use production data in test environments to make integration testing convenient — it is one of the commonest sources of real breaches.

⚠⚠ Data migration is always harder than the estimate, and the reason is always the same

• The technical transfer is the easy part. What takes the time is that the two systems disagree about what the data means, and that the old system contains twenty years of accumulated mess nobody documented.
• ⚠ Profile the source data before you plan anything. You will find duplicates, records that violate rules the old system supposedly enforced, free-text fields holding structured data, and codes whose meaning nobody remembers.
• Expect the definitions to differ. Two systems that both have a "customer" frequently do not mean the same thing by it, and reconciling that is a business decision, not a technical one.
• ⚠⚠ Decide what happens to records that cannot be migrated cleanly — and decide it with the business, in advance, in writing. Silently dropping or defaulting them is how organisations discover a year later that data is gone.
• Reconcile counts and totals after every migration run, and have the business verify a sample against what they expect to see.
• Rehearse the migration on real volumes. A process that works on a thousand test rows can take a weekend on ten million.
• ⚠ Have a rollback plan and test it. A cutover you cannot reverse is a bet, not a plan.
• Keep the source system readable for a period afterwards. Questions arrive for months, and the answer is frequently in the old system.
• "It works in test" is not evidence it works. Test environments have smaller data, fewer integrations, and no real users doing unexpected things.

⚠⚠ Real data carries real obligations — and students meet this first in a database course

• The moment a system holds data about people, it is subject to law and to duties that have nothing to do with whether the code works.
• ⚠⚠ Never copy production data into a development or test environment casually. It is one of the commonest sources of real breaches, it is frequently prohibited by policy, and a development database is almost never secured to the standard the production one is. Use synthetic or properly de-identified data.
• De-identification is harder than removing names. Combinations of ordinary fields — date of birth, postcode, sex — re-identify people surprisingly often.
• Collect only what you need and keep it only as long as you need it. Data you do not hold cannot be breached, and retention is a policy decision with legal consequences.
• ⚠ Access only what your task requires. Broad database access is normal for a developer and querying a colleague's or a public figure's record is still a dismissible act — audit logs attribute it to your account.
• Encrypt sensitive data in transit and at rest, and never store passwords recoverably — they are hashed with a purpose-built algorithm, never encrypted and never plain.
• ⚠ Sector rules stack on top: health data under HIPAA, student records under FERPA, card data under PCI DSS, and Florida's Digital Bill of Rights for businesses meeting its thresholds.
• Report a suspected breach immediately. Notification obligations carry deadlines, and concealment turns a manageable incident into a serious one.
• ⚠ Rule 11 applies — privacy law is moving quickly at state level; verify current requirements.

⚠⚠ Authorisation is the line between a computing professional and a defendant

• Never access, scan, modify, or extract data from a system you do not have permission to touch. The technical knowledge these courses give you is exactly what makes unauthorised access easy, which is why the rule matters more in this field than in most.
• Federal exposure: the Computer Fraud and Abuse Act criminalises unauthorised access to a protected computer, and "exceeding authorised access" has been read broadly.
• ⚠⚠ Florida exposure is separate and additional: the Florida Computer Crimes Act, Chapter 815, Florida Statutes, makes offences against computer users, systems and data punishable under state law independently of federal law.
• Having credentials is not the same as having authorisation. Being technically able to query a table or read a record does not mean you may, and systems log that you did.
• Use the lab and build your own. A local database, a virtual machine, or a personal cloud account costs little or nothing and lets you practise lawfully anything that would be unlawful elsewhere.
• Get scope in writing before any authorised testing or administrative engagement.
• ⚠ Rule 11 applies — computer crime and privacy law changes; verify rather than relying on a course guide.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement — and it is live here, since Daytona State offers both associate-level and bachelor of science coursework in these prefixes.

CEN4801 is 3 credits and approximately 45 contact hours, offered fall only at Daytona State, with COP4708 and COP3530 as prerequisites.

See this repository's COP4708 and CEN4010 guides for the surrounding sequence.