![Principle 3:Service Oriented Architecture (SOA)SOA has many interpretations, definitions and meaningsThe worst interpretation of SOA is making it synonymous to Web Services. Web Services and XML have solved many heterogeneous integration problems; however,SOA is useful when it reaches throughout the enterprise and encompasses not just low-level infrastructural components but also complex business rules, transactions and processesSOA, if done right, must:Be highly process-centric. In fact, SOA should be deployed in an organic conjunction with BPMS Promote and require IT-Business collaboration on identification and designs of transactional bundles to be deployed as Components and ServicesThe ultimate outcome of a SOA initiative should be a complete model of the organization’s supply chain (all mission-critical processes [components and transactions]) via loosely-coupled, reusable Components and Services.](https://image.slidesharecdn.com/architectureandengineering-12976329873034-phpapp01/85/Architecture-And-Engineering-5-320.jpg)
More Related Content
What's hot (20)
Viewers also liked (10)
Similar to Architecture And Engineering (20)
Architecture And Engineering
- 1. Thoughts on underlying principles of IT architecture & engineeringBy E. Meyman
- 2. ContentsArchitecture & Engineering: Six PrinciplesSolutions need to be architected and engineered prior to being developed/programmedTrue Object-Oriented Design (OOD) with its industrially-proven good practicesService Oriented Architecture (SOA)Data CentricityProcess CentricityEnterprise TaxonomyLegacy
- 3. Principle 1:Solutions needs to be architected and engineered prior to being developed/programmedProblem:Too many half-literate buzzword-users claiming to be architects (and being delusional enough to believe it!)Diluted difference between programmer, developer, and engineerResult:Solutions not architected and not engineered. Consequently:Within several years, solutions end up on “life support” (extremely costly to maintain and make changes) and soon – completely unusableSolution:Architecture and engineering should become part of IT cultureEmploy a staff of architects, empower them and measure their performance by the performance of their solutions (don’t get a hollow buzzword-user in place of an architect!).
- 4. Principle 2:True Object-Oriented Design (OOD) with its industrially-proven good practicesIt’s not enough to standardize on platforms and versions. Need to also standardize on the way platforms are used: architecture, engineering, development, programmingOOD is very significant because it enables (and lack of it makes impossible) software modularity and SOA compatibility:Path: Objects –> Components –> FrameworkA component is a meaningful collection of objects
- 5. Principle 3:Service Oriented Architecture (SOA)SOA has many interpretations, definitions and meaningsThe worst interpretation of SOA is making it synonymous to Web Services. Web Services and XML have solved many heterogeneous integration problems; however,SOA is useful when it reaches throughout the enterprise and encompasses not just low-level infrastructural components but also complex business rules, transactions and processesSOA, if done right, must:Be highly process-centric. In fact, SOA should be deployed in an organic conjunction with BPMS Promote and require IT-Business collaboration on identification and designs of transactional bundles to be deployed as Components and ServicesThe ultimate outcome of a SOA initiative should be a complete model of the organization’s supply chain (all mission-critical processes [components and transactions]) via loosely-coupled, reusable Components and Services.
- 6. Principle 4:Data CentricityData is one of the most important asset of an enterprise. Therefore,-Procedurally,Data and Information Management should be a devoted discipline with specifically-identified responsibilities and accountabilityData Management CommitteeArchitecturally, The acceptability of any IT solution must be judged based on its ability to support data mining, searcheablity/retrievability, maintainability, portability, interoperability, security, and integrityLooking beyond user interface and examining how data is handled
- 7. Principle 5:Process CentricityEverything an organization does involves a process; the Supply Chain is a collection of business processesProcesses must be mapped, automated and continuously performance-measuredA SOA-BPMS environment should be utilized for the automationBusiness analytics (based on feedback of respective SMEs) should be derived and embedded into the electronic workflow of automated business processesBenefits: Easy to gather scientific evidence of business process performance, and simulate improvement scenariosEasy to monitor business activity and employ contextual event-listeners
- 8. Principle 6:Enterprise TaxonomyA practical, convention-based categorical/sub-categorical relationship of the organization’s business functions. Example:Function XSub-function X1Sub-sub-function X2Sub-sub-function X…n (location, corporate role, domain of expertise, domain of interest, applications & roles, web content, business processes and SOA components, BI reports & dashboards, customers etc. – the more taxonomical attributes the more complete personalized-customized Web 2.0 experience)Function YA functional “spinal cord” of the organizationRemoves boundaries between- and enables a full-fledge implementation of enterprise’s vital taxonomy-dependent initiatives, such as Portal, BI, SOA, Content Management, Document Management, Project Management, Portfolio Management etc.
- 9. LegacyRevamp vs. Replace decisionA short-term retirement vs. long-term retirementIf “Revamp”, modularize and improve/optimize within current paradigmIf/When “Replace”, recreate application’s functionality via loosely-coupled Components and Services from SOA stack (ideally, legacy apps should be retired when/if its important functionality can be executed via SOA components)Don’t create new legacy by not architecting new solutions the SOA way
- 10. Q & A