end2end Enterprise Architecture - Application Architecture

Editor's Notes

• #2: Welcome to the end2end Enterprise Architecture training programme. This slide deck will complement the 1st, 2nd and 4th sessions and feed into the final 5th session when it all is pulled together in Enterprise Architecture. But it will also stand alone and will provide an insight into WHAT TO DO to deliver on business expectations – and what NOT to do. Unlike other courses the E2E EA series gives you the ‘hands on’ architecture decisions and deliverables, not just possible options or concepts but the tangible actions for your day to day work.
• #3: I will take you through the ‘Architecture Stack’ – how does the layers hang together and what is the handshake from one to the other. We will talk a lot about Separation of Concerns because at the end of the day that is what architecture is all about. I will take you through reusability opportunities – TOGAF talks about the Architecture Continuum, I will take it to the next level at tell you how to achieve that reusability. It is important to understand where we’ve come from – and where we are going, understanding the application architecture evolution just might give you that ‘AHA’ moment. Finally Non-functional requirements specifically in relation to Application Architecture – it’s a packed program, so hang on and enjoy the ride.
• #5: This slide shows you that when you have 4 architects in a room you are likely to have 5 opinions. Some of these statements are poles apart – from the slogan from Enterprise Architects to the comprehensive definition from Gartner, which is what you should keep in mind when working at the domain architecture level.
• #6: This slide I have to contribute to Enterprise Architects. It is giving you the bigger picture that Application Architecture is a component of delivering the business vision and company strategy. When you do design your application it is important you keep this perspective in mind – don’t get into the ‘rabbit hole’ and delivering for a single purpose.
• #7: Getting into the Architecture Stack is difficult without writing a ‘war and peace’. The slide speaks for itself about how the layers are connected and in the end you can’t achieve any one of the layers without all the others. Today we will only cover the Business Applications layer, but look out for the other releases in this training series, including the final one – Enterprise Architecture – which will bring them all together. Outside each layer and across the entire stack you must always observe Architecture Governance, it is applicable to each layer and we will cover the relevance to Application Architecture today.
• #8: Architecture principles provides a boundary for you application architecture and offer a prioritisation of options e.g. ‘rent before buy – buy before build’. On request you can receive a sample principle definition upon which you can establish your own for your organisation, because one size does not fit all – you have to adopt to business language and priorities.
• #9: The most important principle within the application architecture domain, there are several others which we will touch on but your focus should be here.
• #10: The is no application without a business process – Whoa I hear you say, we just need business requirements!!! Yes, but business requirements are the definition of a business process. As an Application Architect you must review the business requirements and make sure they are completed to a level where you can design an application to meet business needs. I propose you adopt the Lean Six Sigma business process model in your business requirements definition because it provides you with everything you need. The SIPOC gives you the first level of Separation of Concerns in Application Architecture it defines your input/output and your source/target as well as the business rules for the process itself – usually business requirements only defines the business rules or process steps leaving you guessing as to what data to use in what currency, where to get it and where to deliver it to.
• #11: Your application structure is the second level of Separation of Concerns. In the early days of IT we would reuse sections of application logic from within other sections of the same (or other) applications – some of you smile, you remember….. JUST DON’T DO IT. Clearly structure your application and break it out into separate components if some of them could be reused by other applications – Yes, we are talking SOA application architecture here, and it makes sense from an application architecture perspective, we will deal with the technology and data implications in separate sessions.
• #12: In every walk of life you have Separation of concerns. Albeit from the same source you would not buy shoes from a butcher or milk from a cobbler! Likewise with your application. Each part of the application must be dedicated for that particular purpose. End-to-End your application architecture must cover all six tiers and as the architect you must make sure that each tier remains true to its purpose. No if’s and not but’s – you must stay true for your architecture to succeed – in terms of performance, scalability, portability, availability, flexibility, maintainability. That’s your target and that’s the reason you must stay true to the Separation of Concerns.
• #13: By observing “Separation of Concerns” in your application architecture you will improve several key objectives: Performance: When you clearly separate the layers of your application you can load-balance individual tiers e.g. you may deploy the business logic layer across multiple application servers and load-balance across them, but may only have two servers in each of the other tiers. Scalability: It is a lot easier and cheaper to scale application servers than database servers, so keep your business logic on the application tier. Also leave workflow controls in the integration layer, if you includes this in the application tier you will create extensive connectivity activity to and from the application server consuming processing resources that could be used for business logic processing. Flexibility: By managing orchestration, workflow and alerting in the integration layer you don’t need to change the application when any of these highly volatile components changes. Likewise keeping business and process logic away from the Client tier gives you flexibility to keep up with the latest technology in the very volatile Client device market.
• #14: Flexibility: by clearly separating your application tiers enables change of technology in one tier without affecting the others, likewise it is possible to implement stronger security controls on one tier than in another. Changes to either the front-end or back-end can be introduced without making changes to the application business logic and hence functional testing and deployment is saved. Cost control: Cheaper technology can be deployed in some tiers and development can be conducted in parallel by separate teams providing better ‘speed-to-market’.
• #15: Reusability is the key to a successful application architecture. Gone are the days when we developed an application for a specific purpose. Doing things once and right is the name of the game.
• #16: Let me introduce the term “application ecosystem” to you. Every component has its place and purpose – and that purpose is not filled in part of in full by any other component. Each component of the application can be activated across organisational and system boundaries.
• #17: We touched on the SIPOC structure earlier. Now we make sure it – the business process – break down the barriers of vertical and horizontal siloes. If the SIPOC (your business definition) is constrained then your application will likely be constrained because the same business process component, which could be a candidate application component, is likely done slightly differently in different siloes.
• #18: Your application architecture MUST cover business process definition (SIPOC) as well as the orchestration of services across platforms and hosting environments. As an Application Architect you have to this enterprise wide, don’t leave it to the enterprise architect – it’s your job. Your application components (some will be services others will not) must be self contained – small applications in their own right. This will give you further technology isolation – and freedom, but please don’t create a mishmash of technology across your application landscape. Finally – a pet of mine – Asynchronous communication wherever possible, this gives you better reusability, scalability, flexibility, performance and availability.
• #19: What we have described in the previous slides is the core of Service Oriented Architecture. Make sure you make your services (or application components) general enough so they can be used by multiple applications – no application will ever use ALL the data or functions made available in a service.
• #20: I’m not going to bring you back to when we wrote programs back in the 70s in Assembler and facilitated reusability by ‘go to’, ‘do until’ and ‘perform’ statements – that was the bad old days. On the road of Application Architecture the journey is guided by roadmaps, frameworks, principles, standards and a lot of other useless stuff…. I will describe this briefly the get back on track on WHAT you need to do to deliver business benefits using application architecture.
• #21: Post the days of my programming days when we though it was cool to call a subroutine in a colleague's program without him/she knowing – calling it reusability, some standards emerged. Firstly with Object and Component based architectures but it was basically externalisation of specific program routines, might as well stayed internal. Then the big break-through with message based integration, who has not been working with IBM’s MQ Series, asynchronous – fire and forget, but it moved significant part of the business logic onto the message broker and created another single point of failure. Now combine these two key developments in application architecture evolution and add the latest definition of service orientation – at all levels, and we have a brave new world.
• #22: One should not differentiate one whether application components facilitates user, application or external functional connectivity – think ECO-System. Everything about your application architecture should evolve around scalability, availability and performance and sometimes one has to sacrifice one to achieve the other…. WRONG, WRONG, WRONG. If that is your frame of mind you need to snap out of your tunnel vision and see your application architecture holistically – end to end. We will touch on some of those details in the coming slides.
• #23: Non-functional requirements is NOT ‘anything not functional’ – non-functional requirements defines the delivery of the functional requirements. The things that will keep your application surviving mergers and acquisitions, infrastructure upgrades and changes in business strategy.
• #24: Loose coupling = asynchronous processing, only use synchronous processing when it is absolutely necessary. Always use a ‘integration layer’ e.g. Enterprise Service Bus or the like, then your user experience can remain intact by accepting the update and guarantee processing later. Stored Procedures is almost a religious subject – but the fact is that a stored procedure must load into a contiguous piece of memory and especially large SP’s may not find that – result the application hang, SP’s also goes against ‘Loose Coupling’ as it is not possibe to migrate MS SQL SP’s to Oracle’s PL/SQL or any other combination. YES – but performance I hear you say, I’ll address that in a later slide!!!
• #25: We have touched on the Sync/Async integration already. Chatty applications are a major cause to poor performance, try to minimise the number of round trips between tiers and components. When using data caching make sure it does not become another instance of a repository but it is truly a caching facility refreshed frequently from the source of truth.
• #26: As an application architect one must have at least appreciation of database and network architectures and technologies, otherwise these resources will be used poorly and affect the performance of the application. While the application architect may produce a logical database design – based on the enterprise architect’s conceptualisation – this logical design must not be implemented as the physical deployment of the database, because it will most likely not work. Get a database administrator involved to define access paths for optimal performance. When designing the user interface be mindful of the user experience, validate what is possible on the fly and in the background. Give the user a different task to complete while the application validates the previous input.
• #27: A few of these have been mentioned in previous slides. Focus on your application’s resource utilisation – a synchronous request is hugging memory and cpu and if you have a bunch of those it can bring your application to a halt.
• #29: Best of bread was a term popular in the 70’s and 80’s and have cost many corporations dearly in maintenance. Make sure your application architecture is coherent and use industry/open standard and – possibly open source depending on the company risk and security policies. Make sure maintenance of each tier require as few as possible skill sets, e.g. if you distribute your business logic across all tiers you will required SQL skills, Java Skills, C# ckills and HTTP skills – plus skills to integrate them all. For most effective maintenance make sure you structure your application as defined in the previous slides and DOCUMENTATION is non-negotiable, and documentation is not comments in the code – it is a written document structured to a standard.
• #30: Right. I have taken you through from the enterprise architecture stack to the depth of application designs. What I have given you here is not a framework or guideline to be copied into a company policy – this is very personal to you as the application architect, for you to have in your back pocket when you open your mouth in meetings or tell some vendor how you want things done. I wish you luck and happy to provide further advice on your professional journey, just email your question through on [email protected] or use the form on our website.
• #31: Your key objective as an application architect is to know and understand the business strategy, objectives and short/medium goals. Without this appreciation you cannot claim to be an application architect, because the business applications must serve these always. I cannot say it enough – SEPARATION OF CONCERNS – this must become a mantra in your mind. Finally a word of warning – don’t believe all the new fads and trends coming out, never go ‘bleeding edge’. It took me 5 years from when I was introduced to ‘data vault’ before I included it in my architecture.