1. Thoughts on underlying principles of IT architecture & engineering By E. Meyman

2. Contents Architecture & Engineering: Six Principles Solutions need to be architected and engineered prior to being developed/programmed True Object-Oriented Design (OOD) with its industrially-proven good practices Service Oriented Architecture (SOA) Data Centricity Process Centricity Enterprise Taxonomy Legacy

3. Principle 1:Solutions needs to be architected and engineered prior to being developed/programmed Problem: Too many half-literate buzzword-users claiming to be architects (and being delusional enough to believe it!) Diluted difference between programmer, developer, and engineer Result: 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 unusable Solution: Architecture and engineering should become part of IT culture Employ 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 practices It’s not enough to standardize on platforms and versions. Need to also standardize on the way platforms are used: architecture, engineering, development, programming OOD is very significant because it enables (and lack of it makes impossible) software modularity and SOA compatibility: Path: Objects –> Components –> Framework A component is a meaningful collection of objects

5. Principle 3:Service Oriented Architecture (SOA) SOA has many interpretations, definitions and meanings The 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 processes SOA, 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 Services The 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 Centricity Data 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 accountability Data Management Committee Architecturally, The acceptability of any IT solution must be judged based on its ability to support data mining, searcheablity/retrievability, maintainability, portability, interoperability, security, and integrity Looking beyond user interface and examining how data is handled

7. Principle 5:Process Centricity Everything an organization does involves a process; the Supply Chain is a collection of business processes Processes must be mapped, automated and continuously performance-measured A SOA-BPMS environment should be utilized for the automation Business analytics (based on feedback of respective SMEs) should be derived and embedded into the electronic workflow of automated business processes Benefits: Easy to gather scientific evidence of business process performance, and simulate improvement scenarios Easy to monitor business activity and employ contextual event-listeners

8. Principle 6:Enterprise Taxonomy A practical, convention-based categorical/sub-categorical relationship of the organization’s business functions. Example: Function X Sub-function X1 Sub-sub-function X2 Sub-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 Y A functional “spinal cord” of the organization Removes 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. Legacy Revamp vs. Replace decision A short-term retirement vs. long-term retirement If “Revamp”, modularize and improve/optimize within current paradigm If/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