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 :)
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!
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 ... ....
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.
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 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.
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!!
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 !!
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 ...
....
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 😁!!
Another great video Jesper! Really succinct and easy to understand. Thanks again!
So much information in 15mins! Excellent video
Thank you Chemsss much appreciated!
Absolutely terrific description. Thank you!
Thank you Frank, much appreciated !!
I am changing my slides for a cto presentation... awesome explanation
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 😁😁😁!
Thanks, that's really so generous and well presented keep up please
Thank you Houssam !!
It's a pleasure to listen to you
Excellent Keep up the good work.
Another excellent video -- thank you!
A splendid job! I commend you for your thorough work.
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.
Thank you, I'm delighted
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
Excellent !
Thank you !!
Very well explained, thanks Jesper!!
Thank you Shekhar !!
Thanks for this great explanation
Thank you Calin !! 😁
Thanks it was very helpful for me
Well, I just figured out what I am going to be watching in the coming weeks ;-)
Very Well Explained. Thanks
Great explanation. Love it 👍
Thanks for the useful information
Useful information
awesome video thanks for sharing
Thank you!!
This is brilliant
Thank you !! 😁
Awesome video , thank you !
My pleasure Kayals!
A well-developed theme!
Wonderful review
Beautiful I like your style.
Amazing as always
Exactly right! Keep it up.
So great video, thank you so so much
Thanks for the review
Everything is excellent
Great content 👌 👏
Thank you !!
Good explanation
Thank you !!
That's a good point. Worthy
Very good
Astounding
I support him
It helped me a lot
Helps a lot
Very cool!
Thank you!
Like the REVIEW
excellent
Appreciated I like
Thank you.
And thank you !!😁
💙💙💙💙 team work = dream work work hard everyday baby this your time .....
Superb tutorial, thank you.
Recommend 100%
Awesome
thanks, bravo
Thank you David!
Subscribed!
Thank you!!
Masterful, do you think it possible to ask me to share the presentation
Please share it !! 😁
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!
This is great
🔥🔥DEFF🔥🔥
👌
Thank you !! 😁
Great EA
Just harmony
I like this country
❤️❤️❤️❤️
It's priceless
🔥🔥🔥
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.
More videos
5 stars
wow
Stable
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
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 😀.
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 😄.
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