Agreed this was a nice way to explain them. A few of my thoughts on why these things have become confusing for some people and yes there are people to blame. An Enterprise Solution - is a System of Systems with common and shared resources and capabilities between the systems - While a stand-alone System/Solution has its own architecture when integrated into an Enterprise, it needs to adhere to the EA principles and use the common features, data, and the technical competence of the Enterprise. The KEY to success of the EA is that it is MODELED properly, implemented intelligently with the right vision in mind that supports future growth as well as answering the right questions for the present needs. We can talk about this a lot, I might start writing a book on the subject - Often people confuse architecting and solutions engineering or architecture with disciplines such as Infrastructure Engineering or Network Engineering (You can 100% blame the HR marketing people who want to be "innovative" to the detriment of finding the right candidates for jobs. Therefore confusing the situation. Not every position is an Architect or an Engineer - There are a ton of positions that should be called Practitioner/SME/Technician - but they are called names like Technical Engineer/Architect to make them sound "trendy" Furthermore, the position description does not match the title). At the end of the day - You can think that the EA is a FAST, large, comfortable, easy-to-drive 18-wheeler that accommodates/replaces your sedan, SUV, Truck, Minivan, and even sports car by integrating them all into one and it offers the one chassis, engine, exhaust system, entertainment package, seat for adult and kids, etc... you got the point while considering the costs, and practicality of its use and operation. I hope it makes sense to you, it does to me because I have been a system Engineer and EA for the past 30 years - If you want to know more - let me know. Unfortunately, I do not have a channel right now - but perhaps in the future where I can help and share.
"Solutions architecture without enterprise architecture creates silos by focusing only on business requirements.” - Absolutely one of the most brilliant statements I've ever heard. You summed it up perfectly. Unfortunately I've experienced numerous companies whose focus was always on the solutions and never the enterprise. This happens in construction in poorer countries. There is no "central planning" or "zoning laws". Instead, each person focuses in the IMMEDIATE GOAL of building their their personal home or dwelling. This results in cities without proper roads, running water or sewer, electricity, zoning laws, etc. Just look at any of the Favelas in Brazil as an example of poor enterprise planning. This perfectly describes many companies and their IT Infrastructures.
EA is not cheap - Achieving it and different levels of it require $$, communication, and planning, and it can take a long time to achieve the goals you set (the Target State) - Those countries that do a poor job on their "systems" also are affected by instability, sanctions, lack of resources, levels of education, bribery, and corruption - We cannot look at every country and how they manage themselves from the lens of how we do things in the USA or more advanced countries with $$ and advanced technologies - Wars often cause those situations in many places where instability is in the forefront of everyone's mind and when they are in a position of power corruption creeps - anyways - it is a long story :)
Dear Content Owner - Big "Thank You" for taking the time and putting the "effort", "energy" to bring the value in this industry via this video. Your video is highly enriching and bringing the passion with the depth to THRIVE ... ....
I borrowed your framework to explain this difference to some of our trainees. The only change I made, was the order. I prefer to always start with the business perspective. And I put Invisible in quotes, because you could argue that in a digital transformation paradigm this is no longer the case. As Gartner said - already many years ago - "There is no business and IT; IT is the business"... Thanks for sharing!
This is excellent Jesper. You've broken it down into real, practical deliverables rather than the usual wishy-washy mumbo-jumbo I often get from Architects.
Hi on track 6:28 you have an Terror on the Diagram on top left side in the Header. The Letter e is missing in the Second Word. You should Name IT conceptual architecture.
An excellent talk. Actually, because this talk is so well thought through it achieves an outstanding level of clarity. It's really quite phenomenal. I don't think I've seen anybody sum up the relationships between Solution and Enterprise Architecture (and their various components) with anything like this level of brevity. First rate.
Hi Epictetus, I did make reference in the video description to the author of the framework, Svyatoslav Kotusev. But you are right, I should have made a reference to it in the vide itself. My apologies.
What's the difference? They all "borrow" each other's stuff...For that matter most of it just writes itself based on what a product does. Think not? The included AWS Reference Architecture is just a diagram of what the product does. Hardly "architecture"... This overall job is one giant fleecing, hats off to a whole group of well paid people who mostly cc: everyone their borrowed goods and call it work. kudos.
ATMs don't use transactions and don't support rollback, it uses compensating actions. I get that this flawed analogy is as old as DTC itself, but at an architect level we need to move on, it has never been 'true'. We are now in a cloud dominated, distributed computing world and need to pay attention when an application shouldn't try to provide strong transactional consistency.
i feel this is missing/ignoring the business process layer in solution architecture as well as HR/org changes and business roles. you cannot ignore that stuff if you want a proper solution. architecture has a certain arrogance to it pretending that only IT exists and matters.
The architecture lacks Solution Cost Estimates, POC, Testing, migration, and DevOps perspectives. Without clear insights into these aspects, none of the architectural artifacts would have meaningful end-to-end context.
This is THE best explanation of enterprise v. solution architecture I've ever seen. Period.
Thank you Marjorie !!
Agreed this was a nice way to explain them. A few of my thoughts on why these things have become confusing for some people and yes there are people to blame.
An Enterprise Solution - is a System of Systems with common and shared resources and capabilities between the systems - While a stand-alone System/Solution has its own architecture when integrated into an Enterprise, it needs to adhere to the EA principles and use the common features, data, and the technical competence of the Enterprise. The KEY to success of the EA is that it is MODELED properly, implemented intelligently with the right vision in mind that supports future growth as well as answering the right questions for the present needs. We can talk about this a lot, I might start writing a book on the subject -
Often people confuse architecting and solutions engineering or architecture with disciplines such as Infrastructure Engineering or Network Engineering (You can 100% blame the HR marketing people who want to be "innovative" to the detriment of finding the right candidates for jobs. Therefore confusing the situation. Not every position is an Architect or an Engineer - There are a ton of positions that should be called Practitioner/SME/Technician - but they are called names like Technical Engineer/Architect to make them sound "trendy" Furthermore, the position description does not match the title).
At the end of the day - You can think that the EA is a FAST, large, comfortable, easy-to-drive 18-wheeler that accommodates/replaces your sedan, SUV, Truck, Minivan, and even sports car by integrating them all into one and it offers the one chassis, engine, exhaust system, entertainment package, seat for adult and kids, etc... you got the point while considering the costs, and practicality of its use and operation.
I hope it makes sense to you, it does to me because I have been a system Engineer and EA for the past 30 years - If you want to know more - let me know. Unfortunately, I do not have a channel right now - but perhaps in the future where I can help and share.
"Solutions architecture without enterprise architecture creates silos by focusing only on business requirements.” - Absolutely one of the most brilliant statements I've ever heard. You summed it up perfectly. Unfortunately I've experienced numerous companies whose focus was always on the solutions and never the enterprise.
This happens in construction in poorer countries. There is no "central planning" or "zoning laws". Instead, each person focuses in the IMMEDIATE GOAL of building their their personal home or dwelling.
This results in cities without proper roads, running water or sewer, electricity, zoning laws, etc. Just look at any of the Favelas in Brazil as an example of poor enterprise planning.
This perfectly describes many companies and their IT Infrastructures.
Thank you, that analogy was very helpful. I now understand the difference between the two.
EA is not cheap - Achieving it and different levels of it require $$, communication, and planning, and it can take a long time to achieve the goals you set (the Target State) - Those countries that do a poor job on their "systems" also are affected by instability, sanctions, lack of resources, levels of education, bribery, and corruption - We cannot look at every country and how they manage themselves from the lens of how we do things in the USA or more advanced countries with $$ and advanced technologies - Wars often cause those situations in many places where instability is in the forefront of everyone's mind and when they are in a position of power corruption creeps - anyways - it is a long story :)
Thank you!!
Dear Content Owner -
Big "Thank You" for taking the time and putting the "effort", "energy" to bring the value in this industry via this video.
Your video is highly enriching and bringing the passion with the depth to THRIVE ...
....
I borrowed your framework to explain this difference to some of our trainees. The only change I made, was the order. I prefer to always start with the business perspective. And I put Invisible in quotes, because you could argue that in a digital transformation paradigm this is no longer the case. As Gartner said - already many years ago - "There is no business and IT; IT is the business"... Thanks for sharing!
Hi Paul, thanks for your feedback! 😁
Watching this as someone who does EA and SA work. This is a very good video.
Thank you !!
This is excellent Jesper. You've broken it down into real, practical deliverables rather than the usual wishy-washy mumbo-jumbo I often get from Architects.
Thank you Simon Wallace !!
As always, your explanations are easy to grasp in a subject that can be difficult to understand.
Thank you Robert 😁!!
I am changing my slides for a cto presentation... awesome explanation
Excellent !
Thank you !!
So much information in 15mins! Excellent video
Thank you Chemsss much appreciated!
Absolutely terrific description. Thank you!
Thank you Frank, much appreciated !!
Hi on track 6:28 you have an Terror on the Diagram on top left side in the Header. The Letter e is missing in the Second Word. You should Name IT conceptual architecture.
Well, I just figured out what I am going to be watching in the coming weeks ;-)
Thanks, that's really so generous and well presented keep up please
Thank you Houssam !!
Thank you, I'm delighted
Another great video Jesper! Really succinct and easy to understand. Thanks again!
This is brilliant
Thank you !! 😁
Superb tutorial, thank you.
An excellent talk. Actually, because this talk is so well thought through it achieves an outstanding level of clarity. It's really quite phenomenal. I don't think I've seen anybody sum up the relationships between Solution and Enterprise Architecture (and their various components) with anything like this level of brevity. First rate.
Thank you for that feedback 😁😁😁!
This video is golden
Thank you !!
Thanks for this. I need to prepare for for my next role which I feel it is related to this. I might need a coach.
Also may I know which resource is this? I plan to invest in a training
Great explanation. Love it 👍
A splendid job! I commend you for your thorough work.
Another excellent video -- thank you!
Thanks for this great explanation
Thank you Calin !! 😁
It's a pleasure to listen to you
Excellent Keep up the good work.
awesome video thanks for sharing
Thank you!!
Very well explained, thanks Jesper!!
Thank you Shekhar !!
Great content 👌 👏
Thank you !!
Exactly right! Keep it up.
Very Well Explained. Thanks
So great video, thank you so so much
Thanks it was very helpful for me
Good explanation
Thank you !!
Awesome video , thank you !
My pleasure Kayals!
Wonderful review
A well-developed theme!
Beautiful I like your style.
Useful information
Amazing as always
Everything is excellent
Thanks for the review
Very cool!
Thank you!
That's a good point. Worthy
Astounding
Thanks for the useful information
💙💙💙💙 team work = dream work work hard everyday baby this your time .....
Subscribed!
Thank you!!
excellent
🔥🔥DEFF🔥🔥
Thank you.
And thank you !!😁
Very good
Helps a lot
I support him
Just great! Thx a lot..;-)
Thank you Chris !!
Seriously, most Consultants still fail exactly inbetween, so this was a great picture to start from.. ;-)
@@chris8949 Thank you!
Like the REVIEW
It helped me a lot
thanks, bravo
Thank you David!
Appreciated I like
Recommend 100%
Awesome
👌
Thank you !! 😁
This is great
Masterful, do you think it possible to ask me to share the presentation
Please share it !! 😁
Great EA
Just harmony
🔥🔥🔥
More videos
❤️❤️❤️❤️
Nice EA
Nice video, but you should really reference the book you took all of this from.
Hi Epictetus, I did make reference in the video description to the author of the framework, Svyatoslav Kotusev. But you are right, I should have made a reference to it in the vide itself. My apologies.
What's the difference? They all "borrow" each other's stuff...For that matter most of it just writes itself based on what a product does. Think not? The included AWS Reference Architecture is just a diagram of what the product does. Hardly "architecture"... This overall job is one giant fleecing, hats off to a whole group of well paid people who mostly cc: everyone their borrowed goods and call it work. kudos.
5 stars
I like this country
It's priceless
Stable
wow
ATMs don't use transactions and don't support rollback, it uses compensating actions. I get that this flawed analogy is as old as DTC itself, but at an architect level we need to move on, it has never been 'true'.
We are now in a cloud dominated, distributed computing world and need to pay attention when an application shouldn't try to provide strong transactional consistency.
Like
Horrible video. Audio is slowed down just to get the upload be longer than 10 mins. Clearly can be heard from 1:45 on
I have absolutely NO idea what you are talking about 😄.
The writing animation is garbage.. its pure distraction 😊
WRONG in more ways than can be described here. Please take this video down until you know what you're talking about.
Happy to engage in a conversation about your beliefs. Prioritise your misgivings and raise the number one "way" I get wrong 😀.
i feel this is missing/ignoring the business process layer in solution architecture as well as HR/org changes and business roles. you cannot ignore that stuff if you want a proper solution. architecture has a certain arrogance to it pretending that only IT exists and matters.
The architecture lacks Solution Cost Estimates, POC, Testing, migration, and DevOps perspectives. Without clear insights into these aspects, none of the architectural artifacts would have meaningful end-to-end context.
Thank you, I'm delighted
Very good
Awesome
Great EA
It's priceless