Deprecated: Use of "static" in callables is deprecated in /chroot/home/a40b7614/774635bdc8.nxcli.io/html/wp-content/plugins/moosend-email-marketing/vendor/moosend/website-tracking/src/Utils/Uuid.php on line 15 Deprecated: Use of "static" in callables is deprecated in /chroot/home/a40b7614/774635bdc8.nxcli.io/html/wp-content/plugins/moosend-email-marketing/vendor/moosend/website-tracking/src/Utils/Uuid.php on line 15 Deprecated: Use of "static" in callables is deprecated in /chroot/home/a40b7614/774635bdc8.nxcli.io/html/wp-content/plugins/moosend-email-marketing/vendor/moosend/website-tracking/src/Utils/Uuid.php on line 15 Deprecated: strtr(): Passing null to parameter #1 ($string) of type string is deprecated in /chroot/home/a40b7614/774635bdc8.nxcli.io/html/wp-content/plugins/moosend-email-marketing/vendor/moosend/website-tracking/src/Utils/Encryption.php on line 8 Deprecated: urlencode(): Passing null to parameter #1 ($string) of type string is deprecated in /chroot/home/a40b7614/774635bdc8.nxcli.io/html/wp-content/plugins/moosend-email-marketing/vendor/moosend/website-tracking/src/Payload.php on line 202 Software Architecture – SoftwareArchitect.ca

Category: Software Architecture

  • How Do Software Architects Make Decisions?

    How Do Software Architects Make Decisions?

    A student asked me a question in my Introduction to Software Architecture course, and I decided to write a bit of a longer answer than usual. So I posted it here. 🙂

     

    How and When Architect decide which technologies to go with?

    I would like to know How and When an Architect decides which technology to go with? If he/she is not having in-depth tech knowledge, how to decide if selected technology is capable of catering the need

     

    Well, that is a big question of course. This course went over the role of a software architect at a high level, but a more practical question is how to decide between two or more options when faced with a tough decision.

     

    So let’s look at a scenario with real products, and figure out which we would like to buy.

     

    Scenario: You know you need to buy a piece of software, but how do you choose which piece of software is best?

     

    You have to go and find a marketing solution. You did your research, and the choices are… IBM Marketing Cloud, Oracle Marketing Cloud, Adobe Marketing Cloud, and Salesforce Marketing Cloud. Yes, four massive companies have named their product the same thing.

     

    So how do you choose which one to go with?

     

    Usually, the way companies do this, is come up with their requirements (part of a RFP). They make a list of features that the product they choose must have, and a list of nice to have features, against which products will be judged against.

     

    In my case, I want a marketing cloud that has the following features, must have:

    • Rock solid security
    • Intelligent folder structure for projects to support all my clients without risk of overlap (multi-tenant)
    • Fine control over which users get access to which clients
    • Proven ability to send high volume of emails
    • Detailed and reliable reporting and tracking features
    • Email automations, funnels
    • Schedule emails
    • Pre-stored templates
    • Customer support by the vendor
    • Cost per user

     

    My nice-to-have features are the following:

    • Can host standalone web pages
    • Support multiple languages for the same email
    • Handle unsubscribes with customizable pages
    • Future roadmap

     

    So you make your lists of features that you’d like to see.

     

    Now for each application, you need to “grade” the application on a score of 1-10 against each of the features.

     

    On a scale of 1-10, how great is the security? Does it integrate with your Active Directory? Can you block IP address ranges? Does is do threat detection and ensure to raise an alert if hackers attempt to get in?

     

    Some applications only do the basics, while others have security features you haven’t even thought of.

     

    You go down the list, and evaluate the software on each feature. If an application doesn’t support something on your must-have list, that’s a big problem. A 0, and possible elimination from contention unless you’re willing to modify your requirements.

     

    Now add up the scores under the must-haves and nice-to-haves.

     

    There will be applications that have a low score compared to the others, and that puts them at the bottom of the list. There will be applications have have a high score compared to others, and that puts them at the top. Easy enough, right?

     

    Now how do you choose between two applications where the scores are similar?

     

    Well if they meet the requirements, and the price is within your budget, it might just come down to picking the one you feel will suit you best. Which one had sales teams that replied to your questions the fastest? Which one has the best reputation for support online? Do you already have this company’s other products in your organization?

     

    There’s no perfect solution. Every architect has experienced the case where you start down the path of choosing one vendor, and then you learn that they don’t support something basic. Or things don’t got as easily as you planned. Such is life sometimes.

     

    But if you start with your requirements, and grading applications based on your requirements, you’ll have “the facts” in front of you on which you can make a decision.

     

  • Azure Service Fabric – Microsoft’s New Microservices Platform

    Azure Service Fabric – Microsoft’s New Microservices Platform

    Maybe you’re heard of the Azure Service Fabric (or maybe not), but WHY would you choose to develop a Services Fabric app? Web Apps seem fine, don’t they?

    Microservices is a relatively new thing on the cloud computing scene, and it’s the newest way to develop an application that is most easily scalable and near-perfect availability.

    Before we get into that, how did we get here?

    Traditionally, many large enterprises maintained their own server hardware on site. This involved up-front and ongoing investment in those data centers which included securing the building premises, providing power and cooling, purchasing backup generators, UPS and HVAC units, acquisition of equipment like servers, routers, switches, cabling, patch panels, rack units etc., dedicated technical personnel to maintain the data centers. Some of the disadvantages of this model were a lot of time and effort involved in provisioning new services, over-provisioning, planning ahead of demand, the time required to acquire new infrastructure. All this made the process of hosting time consuming and cumbersome. Also, this was often a roadblock for companies whose core business was not IT.

    With the advent of cloud computing, enterprises now have the option to host their IT infrastructure and applications over the cloud with much more ease and simplicity. They can get rid of the burden of building and maintaining their own data centers to host their services and application thereby freeing up resources and time to focus on their core business. Some of the major players in cloud computing are Microsoft Azure, Amazon Web Service (AWS), Google Cloud, Century Link, Rackspace etc. Some of the key services offered by these players include Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS).

    Platform as a Service (PaaS) offers customers to directly deploy their applications onto the cloud without having to deal with the underlying infrastructure layer over which your applications are hosted on. Azure is fabric is a PaaS service offered by Microsoft Azure. Service Fabric provides several features to the applications deployed like high availability, backup, disaster recovery, scalability, high performance all of which will be taken care of by the respective cloud service provider thereby allowing you to concentrate on the application part.

    Azure Service Fabric is a distributed systems platform which helps you to package, deploy and manage scalable and reliable app services and also addresses the significant challenges in developing and managing cloud applications. By making use of Azure Service Fabric, app developers and administrators can avoid dealing with complex IT infrastructure problems and focus instead on implementing mission critical, demanding workloads which are highly scalable, reliable and manageable. It represents the middleware platform for building and managing next-generation, enterprise-class cloud-scale applications. Azure Service Fabric provides a host of services including life-cycle management, independent scaling, rolling upgrades, always-on availability.

    Azure Service Fabric is not limited only to the Azure platform. You can deploy and use it on any public cloud (AWS or Google etc.), your own on-premises private cloud. For developers, there is SDK for Azure Service Fabric which you can install on your machine and get the same features. Service Fabric helps you build applications with any of the languages, frameworks or runtimes of your choice.

    Azure Service Fabric comes free of cost. There is no charge for Azure Service Fabric components. However, in case you are using Azure Service Fabric within the Azure cloud, you will be charged for the virtual machines that you are using.

    The figure above illustrates some major advantages of Azure Service Fabric over Azure cloud service. With Azure Service Fabric, you don’t have to pay for dedicated instances thereby saving costs. Also, it provided faster scaling and takes care of the upgrades.

    The way Azure Service Fabric works is you deploy the Service Fabric on a bunch of nodes (read VM’s) which forms a cluster. When you deploy your code theoretically it gets deployed on each of the nodes in the cluster.

    The table below lists some of the Azure Service Fabric infrastructure services which would be running on each of your nodes within the cluster along with the function they should be performing:

    Azure service manager offers high availability built-in as compared to Cloud Service wherein you have to manually specify the number of worker and web roles to manage high availability. This is achieved with the help of failover manager. Failover manager keeps a track of the nodes and what services they are running. The moment a particular node goes down it identifies the services which it was running and try to bring them up on other nodes.

    Another important reason why you should be choosing Service Fabric over traditional offerings is it reduces your maintenance effort and costs. You do not have to take care if your underlying infrastructure is up-to-date with latest patches. The upgrade service takes care of it. Time and now the Service Fabric team keeps on upgrading its various components. The upgrade service takes care that all nodes have the latest update running.

    Azure Service Fabric offers better and optimized use of the hardware resources. The nodes that you deploy the Service Fabric on can be simultaneously used for hosting instances for different tenants and various services. This is a shift and advantage over the traditional cloud service offering wherein you had to dedicate VM’s to host services for a particular tenant. Azure Service Fabric with built-in services takes care of the load sharing part between the instances making sure you get the best possible performance for your application.

    There are three ways to administer Service Fabric via REST API, PowerShell and fabric client (.net class). Applications hosted over the Azure Service Fabric are much more easy and faster to scale. Whereas in traditional offering it would take about 15-30 minutes to scale up or down a particular number of instances in Azure Service Fabric it’s just a matter of seconds to increase or decrease the number of instances. This offers much more scalability to the application administrators to scale up or down their applications to meet the ever-changing demands. Azure Service Fabric provides a detailed health check and monitoring system wherein it can check and monitor each of its entities like clusters, nodes, applications, services, deployed service packages, partitions, instances etc. giving a greater in-depth look inside your system to detect any faults or performance issues. When you query the health of an entity it gives you the aggregated health of the entity and all its child descendants thus providing you with a better visibility.

    For application upgrades, Azure Service Fabric uses a technology called “upgrade domains” wherein you can perform in-service application upgrades wherein the customer can keep hitting your application while the upgrade is in progress. This is achieved by segregating your instances into upgrade domains (UD). You go about upgrading one upgrade domain while the instances in other upgrade domains continue to serve your application to the customer. Once this UD is successfully upgraded you move onto another UD. The more the number of upgrade domains the greater scalability you can achieve.

    So the next time you want to host your application onto the cloud, have a look at Azure Service Fabric with all of the features and services it has to offer. It might make your life easier.

     

  • Get Top Architecture Courses at Great Price

    Me2Hi there. Wanted to make a post today about my Udemy courses, and how you are able to get them at a discount using the links below.

    I really appreciate all of my students, and I have created these courses to help pass these architecture exams. I am constantly improving them, and so they’ll never be out of date to the specific exam that they teach.

    “Excellent content that covers the organization of TOGAF very well. Scott’s insights into the exam have been invaluable!” – Vinoo Palayoor

    TOGAF1

    TOGAF2


    “I really appreciated the content and how the whole lectures and material is organized, the small quizzes and the outside material hyperlinks. Really helpful !” – Jean-Francois Pezet

    TOGAF Part 1 Arabic

    Azure 70-534


    I have over 21,000 students in my architecture courses, and I look forward to having you as a student.

    Scott

  • Top Challenges of Enterprise, Software and Solution Architects

    Top Challenges of Enterprise, Software and Solution Architects

    A week or so ago, I ran a survey of the students in my architecture courses, asking them what their biggest challenges were.

    In this post, we’ll look at the top 5 answers, from real working architects and senior application developers like you:

    1. Dealing with Legacy Systems

    Without a doubt, as we get into the 40th year of having enterprise-level software systems, we’re all feeling a bit burdened by some of these pain-in-the-neck (and difficult to replace) systems.

    In fact, as I look back on the last 10 years of my career, I can’t really think of a project that wasn’t something like these:

    • a system where the original developer is gone, and no one fully understands the system
    • a system where, for whatever reason, no one wanted to have to touch if at all possible
    • a system that has been “planning to be replaced” for several years, with no concrete schedule as to when
    • a system where the original vendor doesn’t even support it any more (or indeed talk about it on their website)

    If I had a magic wand, and could update to the latest version, or replace it with something more modern instantly, for sure that magic wand would be used a lot. Unfortunately, company’s sometimes prioritize certain things very low on the list, and we have to deal with them.

    2. Explaining the Value of Architecture to Non-Architects

    Oh man. What is architecture? What IS it? What do architects DO?

    This question has been haunting people in the architecture space for ages. I even made not one, but two videos about it. (Please check those out, and subscribe!)

    The thing to remember is, every system has an architecture. Whether an architect was involved or not, one or more people made some decisions on systems design that add together to become the system architecture. But would you rather have something that is designed intentionally, or something that just comes together without forethought?

    If I offered you a house, and said that I built it one room at a time without thinking about any of the other rooms, does that sound like a well-designed house? Then why can computer systems (and ultimately the businesses that run on top of them) be designed only one room at a time and expect the whole house to make sense?

    (Why are there 3 bathrooms in the basement and none upstairs by the bedrooms? Because there was no architect.)

    3. Dealing with Application and Data Security

    In 2016, security is a huge issue that anyone in technology has to deal with. Not only is it smart business policy to protect your customers data from being exposed, but it’s actually the law in many places that this data has to be responsibly protected. As architects, we need to be on top of the standards for security and ensure that our designs have thought about that before code has been written or systems set up.

    Easier said than done, of course.

    But from the way customer data is kept, to the way our networks are hardened from attack, to the limitations we place on users from outside (including the website user itself which will minimize the effects of a web-facing break in) are more important than ever, and will never be something we can take for granted.

    4. Dealing with integration with other systems

    Legacy systems were a big headache, but even interacting with non-legacy systems can be complex. How do you package and send GBs of sensitive data from one server to another when the other system only accepts XML files in a specific file directory as input? Sometimes you end up with middle-tier “connector” systems that just move files around, and sometimes you need to use third-party solutions like Microsoft SQL Server Integration Services (SSIS) or Microsoft BizTalk to pass and manipulate data around.

    The ideal solution is for two systems to be designed to talk to each other, or use some industry standard protocol (an Industry Architecture on the Enterprise Continuum!) so that related systems can just work to implement a standard instead of worrying about direct integration with so many varying systems. But those standards are often overly complex (due to the number of irrelevant-to-you scenarios they have to deal with) or don’t exist for your specific need.

    5. Feeling locked in with a single vendor, such that parts of the architecture cannot be changed

    We’ve all been there. Your company has been using “Tool X” for analytics and reporting so long that the code is everywhere. In every web page, of every website. Highly customized for button clicks, opt-ins, video plays, and all sorts of events. And implemented slightly differently in every site it’s been added to. When asked, you estimate 12 person-months to swap out the “Tool X” code and replace it with another solution to the same level of customization for pages and events.

    Sometimes you’re stuck. The cost to replace something doesn’t give the business the necessary return on investment to spend that money. And so you go year after year, with a tool that no-one really likes, paying more for it than you probably should, because it’s tool difficult to replace.

    There’s no easy solution to that, except to vow that the next time you’re asked to implement some custom third-party code in all your web pages, you devise a system that puts that code in one central location. You need to abstract that and centralize it, so that it’s easy to upgrade to the newest version or swap out to a new vendor.

    Those were the top 5 issues identified by my students. Anything that I missed?

    [activecampaign form=7]

     

  • Change Happens – It’s All About How to Handle It

    AreYouReady

    Those of you studying for the TOGAF certification may see that “change management” is mentioned in a few places throughout the specification, with slightly different contexts.

    Requirements Management is the center of the ADM hub, and has managing changes to requirements as it’s primary task. Phase G talks about handling change requests during development and implementation of the solution. And Phase H has to do with monitoring for changes in the business landscape, and handling those changes.

    So what’s the difference? Or is there a difference?

    The center of the hub is easiest to deal with. The ADM Requirements Management phase (which is not really a phase since it’s always operating) is a process for ensuring that any requirements that change while the ADM cycle is in progress get captured and handled. We cannot expect that, once the business requirements have been identified and signed off on, that for the next several months (during the rest of the requirements phases, into planning and implementation) that the business requirements cannot change. We all know that companies NEED to react to changes in a more dynamic (yet controlled) fashion, and this phase allows you to deal with each change as it happens, and make decisions as to how it impacts the process you are currently undertaking.

    For example, you might be past the business requirements phase (phase B), and working on the technical requirements (phase D). And a change request comes in that says that the business owner now expects there to be 50 new retail stores added this year, instead of 20. The solution you are designing and developing needs to be able to handle quicker growth.

    Now it may be that this information has no impact for you. The solution that you are proposing and in the process of designing can handle growth the same whether it`s 20 new stores or 50. There may be no impact at all. And so you update the business requirements document, ensure the application and data requirements are not impacted, and resume work on the technical requirements. You might be able to do all that in a single day.

    But perhaps your solution cannot be rolled out that quickly. Given the date you expect the solution to be complete, and the amount of time it takes to upgrade existing stores, handling 50 new stores this year might be a very difficult or impossible task. So this could very well push you to stop Phase D, go back into Phase B, and re-imagine a better solution that allows for quicker completion and rollout. This is just a hypothetical example, but the nature of the change does alter the way you react to it.

    Within Phase G, the solution is already designed and the development team has the task. Your role in Phase G is compliance, and so what do you do if the solution cannot be compliant to your designs? For example, you were counting on the ordering system to be able to update the customer relationship management (CRM) in almost real time. Within minutes of an order coming in, the customer record is updated to reflect that. This allows customer service agents to be able to talk to recent orders placed without having to go into the order system specifically. But during the development or deployment, it is realized that for performance reasons, there will be a 4-8 hour delay in getting orders updated inside the CRM. This is not compliant with your requirements, and in violation of the architecture contract.

    So what do you do then? Most likely, you do NOT stop what is happening and go back to Phase C (Data Requirements). You most likely have to either accept that the solution will initially be non-compliant (a dispensation), or come up with some temporary solution (a new system that will pull the orders in near real time and update the CRM) and deal with it properly the next time through the ADM. Again, it’s a hypothetical example. But how you handle change in this phase is specific to the context of this phase.

    Finally, in Phase H, the solution is deployed and you are monitoring the architecture landscape for change. You are actively looking for it. You are looking for a degradation in performance of certain systems (slowly falling out of compliance with the performance requirements), looking for new technologies or changes to the industry. And of course changes can come from within as businesses wish to make small tweaks here and there without needing to kick off a full ADM round again. If you are in Phase H, you do not need to “go back to Phase B” because there is no active ADM cycle going on at this point. You either handle the change (of course, this includes keeping the baseline requirements up to date) or defer it to the next cycle.

    Change is constant in business. And the TOGAF ADM has several ways to handle it.

     

  • Software Architecture vs Software Design

    Software Architecture vs Software Design

    Here’s the latest from the SoftwareArchitect.ca YouTube channel.  Would love to have you check out the channel or subscribe.

    One of the challenges of being in software architecture is dealing with the question, what is it? What is software architecture? And what is the difference between that and software design?

    In this video, I try to explain the difference between architecture and design. It all has to do with the 30,000 foot view versus the detailed view.