1 Enterprise ArchitectureSession 2 Enterprise Architecture
2 Purpose of today’s sessionIs not to turn you into enterprise architects The field is enormous and the techniques can get quite complex There are “languages” that need to be learnt, such as UML and ERDs (more on this later) To be recognised as an architect you have to complete courses and pass exams At best I would hope that you become familiar with the concepts and understand the role of EA within the organisation Perhaps at work you’ll even be able to say something like “…shouldn’t we be thinking of some form of EA? The benefits could be…” and really impress the CEO
3 Imagine building a house …With no architectural plans With only general sketches as to how its supposed to look, or with only detailed diagrams for the plumbing and wiring With each sub-contractor doing whatever he/she feels like doing Where the whole house has to be torn down in order to remodel one room
4 You may just get
5 Or …
6 Status quo It is often the case that:there is no considered corporate strategy there is no considered IT strategy no thought has been given to business models business processes are not aligned to the corporate strategy names and addresses are stored in more than one place? systems from different suppliers don’t talk to each other? different operating platforms or versions of operating systems are installed on a company’s PCs? different standards exist to interface with a range of back and front office systems?
7 Consequences … The consequences of these simple examples are significant systems do not deliver against the strategy systems do not communicate with each other multiple skill sets are required to manage the problems maintenance of the data is a huge problem – it is rarely in sync drain on resources which means that other, important things don’t get done and much more …
8 Definition An Enterprise Architecture (EA) is a [conceptual] blueprint that defines the function, structure and operation of an organization. It establishes order, structure and standards, which if adhered to can greatly enhance the efficacy of an organization.
9 Standards Think large organisations. Think of these examples:Hardware : mainframes, mini computers, PCs, Apple Operating systems : mainframe, mini, Windows, Linux, IOS Development environment : Druple, Python, Ruby, Visual Studio, .Net, VB, C#, Java, HTML 5, …. Programs and versions : Office 97, 2003, 2007, 2010, 2013 Databases : Oracle, SQL, MySQL, ProgreSQL, IBM DB2, … Interfaces : User, APIs, protocols
10 ENTERPRISE ARCHITECTUREGOVERNANCE The chicken and the egg ENTERPRISE ARCHITECTURE Structure Risk Standards Business processes - rationalized Procurement
11 Knowledge Management Tacit (individual knowledge) vsExplicit (organisation knowledge) What are some of the issues?
12 Knowledge management Disparate, non integrated, systems:Compartmentalise knowledge Think of key spread-sheets that are “privately” owned Are prone to error – we expect rigorous testing of our IT systems – what about financial spreadsheets? Result in duplication of effort What happens when the owner leaves?
13 Knowledge management Loss of information is a threat to the organisation Challenge to convert tacit to explicit knowledge Examples of explicit: documents, files, intranet, minutes of meetings, manuals, SLAs, agreements, spreadsheets, etc Issues ?
14 Knowledge management Loss of information is a threat to the organisation Challenge to convert tacit to explicit Examples of explicit: Documents, files, intranet, minutes of meetings, manuals, SLAs, agreements, spreadsheets, etc Issues Knowledge is power How to store the knowledge so that it is accessible
15 Simple perspective Michael Platt (Microsoft) suggests an EA contains four views: business perspective defines the processes and standards by which the business operates on a day-to-day basis. application perspective defines the interactions among the processes and standards. information perspective defines and classifies the organization’s raw data (such as document files, databases, images, presentations, and spreadsheets). technology perspective defines the hardware, operating systems, programming, and networking solutions used by the organization.
16 Who owns the process? We have seen that EA, according to Michael Platt, contains four views – business, application, information, technology. Who should own the process & what are the implications? business? IT? governance? if none of the above, then who?
17 Formal models There are a number of formal EA models, including inter alia: ZIFA (Zachman Institute Architecture Framework - TOGAF (The Open Group Architecture Framework - PEAF (Pragmatic Enterprise Architecture Framework - GWEA (Government Wide Enterprise Architecture - gwea-framework - TOGAF® 9) … and many more
18 Differences There are differences in emphasis and focus – e.g. IT versus business architecture. Each framework has its proponents and detractors. They all attempt to present an organizational blueprint.
19 From here to there In most instances, the EA involves mapping the “as-is” and “target“ systems Enterprise Architecture TARGET AS - IS GAPS By doing this, the gaps become obvious !
20 Zachman Framework WHAT HOW WHERE WHO WHEN WHY TOOLS SCOPE & VISION List of things Important to the business List of processes the business performs List of locations in which the business operates List of organizations & roles important to the business List of events/cycles important to the business List of business goals and strategies PLANNER BUSINESS MODEL Entity relationship model Business process model Business logistics System / locations model Organizational unit & role relationship model Event model Business Plan / goal relationship model OWNER SYSTEM MODEL (LOGICAL) Logical data model diagram Process diagram Distributed system architecture / location diagram Role relationship diagram Event diagram Business Rule Model / diagram DESIGNER TECHNOLOGY MODEL (PHYSICAL) Physical data model System design / function specification Location / network specification Role specification Event specification Rule design BUILDER DETAILED REP-RESENTATION Data definition Program / process definition Network Architecture / location details Role definition Timing / event definition Rule definition SUB-CONTRACTOR FUNCTIONING ENTERPRISE DATA FUNCTION NETWORK PEOPLE TIME MOTIVATION FUNCTIONING ENTERPRISE A taxonomy rather than a framework – describes the artifacts, not the process
21 Zachman Framework (another view)planner owner business model designer business processes builder agnostic sub-contractor detailed functioning enterprise
22 How can Zachman help? Five ways in which the Zachman grid can help in the development of an EA - it can help: ensure that every stakeholder's perspective has been considered for every descriptive focal point improve the information by sharpening each focus points to one particular concern for one particular audience ensure that all of the business requirements can be traced down to some technical implementation convince stakeholders at the upper levels that the technical team isn't planning on building a bunch of useless functionality convince the technical team that business is including IT in its planning. Roger Sessions
23 TOGAF (in a nutshell) Is about Process ! Business architecture - describes the processes the business uses to meet its goals Application architecture - describes how applications are designed and how they interact with each other Data architecture - describes how the data stores are organized and accessed Technical architecture - describes the hardware and software infrastructure that supports applications and their interactions Roger Sessions
24 Zachman tells you how to categorize your artifactsTOGAF gives you a process for creating them They complement each other !
25 Gartner “Architecture is a verb, not a noun… it is the ongoing process of creating, maintaining, and, especially, leveraging an enterprise architecture that gives an enterprise architecture its vitality “An architecture that is just a bunch of stiff artifacts that sit in a corner gathering dust is useless, regardless of how sophisticated your taxonomy is for categorizing those artifacts or how brilliant your process is that guided their development “Gartner believes that enterprise architecture is about bringing together three constituents: business owners, information specialists, the technology implementers. If you can bring these three groups together and unify them behind a common vision that drives business value, you have succeeded “Success is measured in pragmatic terms, such as driving profitability, not by checking off items on a process matrix.
26 So, where’s the problem? Large organizations tend to be complex entities, and producing a comprehensive EA can be a daunting and expensive task. The more complex the EA, the greater chance it will: Be ignored Not be updated on an ongoing basis Producing and EA is not a once-off task. It requires an ongoing commitment and has to be kept up to date. The minute it falls behind, it becomes worthless.
27 The challenge … Is to develop a manageable and “agile” EA that can be used as a reference and that can be easily kept up to date. This is a big challenge – the literature suggests that the agile architectures are not significantly simpler that the bigger, more complex ones.
28 Now perhaps at work you’ll even be able to say something like:“ Shouldn’t we be thinking of implementing some form of EA? Some of the obvious benefits to the organisation could be: a realignment of business models and processes to support our corporate strategy a better alignment of business and IT improved governance a set of standards for users, APIs and data communication between applications reduced IT costs because we can standardise our hardware, operating systems and software reduce the skill-set needed to develop, implement and maintain our systems reduce our training costs because everyone would be running the same software on the same platforms reduce the duplication of effort because we will have rationalised our business processes and will be able to reuse the algorithms better ” … then casually turn on your heel and leave the now-deathly-silent room
29 End of Section
30 UML = Unified Modeling LanguageNEXT UML Use Case diagrams Actor Use Case Association UML = Unified Modeling Language
31 UML Activity diagram Activity Final node Initial node Flow Merge JoinNEXT UML Activity diagram Activity Final node Initial node Flow Merge Join Fork Decision Condition
32 Entity Relationship Diagram (ERD)NEXT Entity Relationship Diagram (ERD) STUDENT Name Address Student_Number _Address Cell_Number Date_of_Birth Each school enrolls Each student attends at least zero at least one and at most many and at most one students school Name Address Telephone_Number SCHOOL
33 BACK Simple ERD