Some of the key use cases focused on
1. IoT in Factories - operation management
2. IoT in Cities - traffic control, safety and health
3. IoT in Retail - self checkout, customer relationship
4. IoT Vehicles - reduce insurance
5. IoT Homes - safety and security,
for details on various cases, visit
Metrics would be drawn up with your stakeholders, e.g. IT Operations, IT Risk/Security, Financing/Contracts and the Business. Metrics will vary from enterprise to enterprise, but will typically include conformance to the Architectural and Strategic direction, meeting a set of design principles, meeting a list of security requirements, passing a pre-production checklist, some proof that all contracts and commercial arrangements have been addressed, etc.
You'll see from the stakeholders that EA is wider than just IT and solution conformance is required wider than just IT metrics such as performance and reliability.
Thanks for the question, Priya.
I assume you mean how do you describe and document your architecture according to the model.
I would take each section of the model and ask myself "what do we have in this category?" You will come up with gaps - you don't have anything or you have it but it hasn't been described/documented. In the latter case it's an opportunity to document it - an activity that is part of an EA practice.
As I mentioned in an earlier question, the ROI of EA is not easy to calculate. Successful EA bears fruit over a period of time - often even 5 years. It is possible to measure some aspects of ROI and one could start with what's wrong or can be improved as is evident from your as-is EA view. Measure the cost of IT, for example, or the stability of your platform(s) and technology(s) or the product diversity. Then measure these again to see if they have improved as you progress along your EA roadmaps. Also, measure your stakeholders' satisfaction with what they're getting from EA in the short-and medium term.
Thanks for the question, Sandra.
I would say that a medium sized enterprise would have most of the typical aspects of architecture in their EA scope. TOGAF would work well and so would Zachman - to name two! There are many EA frameworks out there, including a rather sophisticated one from Gartner. Maybe you need to take a closer look at TOGAF and Zachman and see which one you're more comfortable with. You can of course also develop your own custom framework and still apply TOGAF's ADM methodology to go about your EA business.
This could be done at least at two levels:
Firstly, the scope should be as agreed with the enterprise stakeholders when the EA practice was defined. The extent/reach of the EA and the roles that the various parties perform - in and outside of the Architecture team - should be as agreed. If the EA does not include, say, a particular business unit, it is sad, but as long as it's been agreed, the scope is still correct.
On another level there are various architecture domains that can be argued as in or out of scope. There are some typical "layers", e.g. Business, Information, Applications and Infrastructure. I would see all these layers as part of the EA scope. Domain definitions vary between platforms, technologies, applications, etc. but should cover all IT capabilities in the enterprise.
A successful EA practice will have various touch points with Business, ideally according to an engagement model. This ensures proper communication with Business and flow of information and delivery between the two parties according to their needs. For example, when Business gets an idea for a project, Architecture is immediately involved to validate the technology impacts and to assist in the project's potential needs going forward. In any EA practice there should be a domain called "Business Architecture" and this is testament to the critical part Business plays in EA. If the activities within that domain are carried out, Business has no choice but to be aligned with the EA.
I assume the question is how EA helps to manage complexity and change management.
Complex organisations often have an IT landscape consisting of various platforms, technologies and solutions. These can have inter-dependencies and impacts on each other. To use a simple example, the desktop might have conflicting applications or applications that require different hardware or operating systems. If the EA is properly documented/modelled, these dependencies are all understood and they can be managed better - and work can bbe planned to remove dependencies over time.
Change management - if we take the example of introducing a new technology or software (the change) and the potential impacts on the IT landscape: Impacts can be highlighted earlier and managed better or avoided. This is where an EA tool can make a big difference, as these allow you to model dependencies for automated impact analyses.
Thanks for the question, Vijaykumar.
In both cases there are benefits from EA.
For existing large setups the potential benefits are, for example, cost reductions in the IT operations and from streamlining the solution set. If the EA is run efficiently, it can play a crucial role in making the enterprise agile, i.e. its ability to adapt to changes. Especially large organisations cannot always adapt easily, but if they have a handle on their EA they have a much better chance.
For greenfield implementations the benefits are that the organisation has the opportunity to define EA principles, standards, guidelines and views from scratch, and being able to apply an Architecture method such as TOGAF from scratch. Following a standard methodology means a higher rate of success for the project, as all aspects will be considered in the Architecture. Greenfield organisations don't have a legacy of bad technology, troublesome solutions and historical bad decisions to accommodate - their focus can be on the presence and the future.
Enforcement of a framework will succeed if people benefit from using it. A framework should facilitate common understanding of how the EA is approached and executed. It should help the EA practice "get its arms around" the EA, giving it reassurance that everything is included. Whatever is excluded, was excluded intentionally and with the assurance that it was at least acknowledged and not ignored. I have seen the use of a (custom) framework as the point-of-entry into the elements stored in the EA knowledge base of the enterprise. So, all the outputs of the practice is organised according to the framework, which clearly reflected different architecture domains, levels of the EA and even Application/Solution groupings. Entrenching a framework in such a way will ensure its use by all stakeholders.
I saw a webinar recently that dealt with justification of EA, so I won't repeat the good answers that surfaced there.
Regarding the assessment of progress and value delivered, a couple of things can be earmarked for regular measurement, as mentioned in our webinar. Additionally, a good way to assess value delivered to the enterprise is to measure the satisfaction of the stakeholders who interact with the EA practice. They were identified as stakeholders because they were supposed to get some benefit from participating in the EA practice, or the EA practice was supposed to get some benefit from having them as stakeholders. Re-visit these and a picture will quickly emerge whether EA adds value.
Often with difficulty!
To start with, don't allow projects to start up and then present their objectives for Architecture approval at a later stage. Architecture should participate at the level where decisions are made on what projects to run and when. Projects should somehow contribute to ultimately reaching the goals defined in the roadmap. Project are opportunities to change small bits of the IT landscape - often not benefiting the business directly but contributing to ultimate technology objectives being reached.
The difficulty is that most organisations have to run projects (due to business pressure) that are not always aligned with EA Roadmaps. Architecture cannot always say no to these and inhibit the business, unless it can be proven that the risk level is too high (for business and/or IT). So, compromises are called for - maybe the EA roadmap objectives have to be re-shuffled or re-scheduled.
Very good question!
Architecture ROI is a tough one and often only visible over a number of years. It's mostly the culmination of various individual strategies and "smaller" road maps that ultimately shows results. If your current IT landscape/architecture is not ideal and needs work to arrive at a better future, you could start with everything that's wrong and ultimately measure how much these wrongs were corrected. Examples: Does it cost too much to run your current IT - it should cost less in the future. Are there unacceptable levels of production failures or instabilities - these levels should be at an acceptable low in future. Do you have end-of-life solutions or technologies that pose a risk to your business - these should be eliminated/replaced, reducing the risk in the future.